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BEKÖSZÖNTŐ 


UTRAVALÓ 


A nyári napok a szakmai gyűjtőmunkára is 
megfelelő alkalmat kínálnak. 


ozgalmas évadotzárunka TechNetMagazin mostani számával. Ritkánvan lehetőségünk 
egyetlen éven belül ennyiféle technológiai újdonsággal megismertetni az olvasót, mint a 
Windows Server 2008 és a SOL Server 2008 megjelenéséhez kapcsolódóan. A rengeteg 
új információ közül igyekeztünk mindig olyanokat kiragadni, amelyek nemcsak újdonság mivol- 
tukban érdekesek, hanem a napi gyakorlatban is hasznosíthatók, legyen szó biztonságról és meg- 
bízhatóságról, magas rendelkezésre állásról vagy éppen a virtualizációban rejlő lehetőségekről. 

Arra biztatok minden olvasót, hogy forgassa a lapszámokat a kicsit nyugalmasabb nyári na- 
pokban és a nyári szabadságok ideje alatt is, akár újraolvasva azokat a cikkeket, amelyekre év 
közben csak a metrón vagy a buszon jutott idő. Egy-egy írást újraolvasva én magam is minden 
alkalommal találkozom olyan új gondolatokkal, amelyeket érdemes továbbgondolni, olyan ötle- 
tekkel, amelyeket érdemes kipróbálni. 

Jó alkalom lehet ez a nyugalmasabb időszak arra is, hogy listát készítsünk magunknak a 
számunkra legfontosabb technológiákról, további információkat gyűjtsünk bevezetésük előtt, 
vagy éppenséggel mielőtt vizsgát teszünk belőlük. A magunk részéről igyekeztünk sokféle tar- 
talommal és hasznosítható háttérinformáció-gyűjteménnyel segíteni az elindulást. 


A szerzői csapat nevében kellemes nyarat és sikeres gyűjtögetést kívánok! 
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Attérés Windows Server 2008-ra, Active Directory és hálózati újdonságok 
2008. augusztus 4-8. 


5 Windows Server 2008 Active Directory és hálózati újdonságok Windows Server 2003-as vagy 
"Windows 2000-es rendszergazdáknak 
issítse ismereteit az új verzióra és készüljön fel a hivatalos MCP vizsgára! 


Rendelje meg a képzést kedvezményes, e-learning tanfolyami utalványokat és MCP vizsgát is 
Frtalinazó tanfolyami csomagban! 


Windows Server 2008 cluster szolgáltatások 
2008. július 7-9. 


e. Haladó tanfolyam rendszergazdáknak, cluster üzemeltetőknek a téma egyik legjobb 
szakértőjének előadásában 

s. Windows Server 2008 failover cluster, storage, NLB, virtualizáció, iSCSI és Fibre Channel 

megoldások áttekintése, multi-site clustering 


Most ajándék Windows Server 2008 Inside Out Microsoft Press kiadvány! 
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Apró ötletek az első lépésekhez. 


virtualizációs technológiák megítélése korántsem egységes az informatikusok körében. 
Vannak, akik számára már teljesen természetes, hogy a felügyelt rendszereik egy része 
virtuális gép. Az óvatosabbaknak ez a technológia még inkább csak játék. A cikkel to- 
vábbgondolós játékra csábítom az utóbbi tábor tagjait is, bízva abban, hogy a technológián túl 
mutató érvek közül is találnak megfontolandót. 
Csaknem két évvel ezelőtt jelent meg a TechNet Magazinban Lepenye Iamás kollégám 
Tervezz merészen! című cikke. Ajánlom mindenkinek újraolvasásra. Akármekkorát változott 
ugyanis időközben a virtualizációs technológia, a megközelítés, a konszolidációs feladat meg- 


valósítására alkalmazott módszer a mai napig megállja a 


összehangolására is, hiszen a folyamatokat ne- 
kik kell végrehajtaniuk. Tehát igazából akkor 
állunk készen, ha az alapvető munkafolyama- 
taink már rendben vannak, és van tartalék 
kapacitásunk a virtualizációs technológia be- 
vezetésének idején jelentkező többletfelada- 
tok elvégzésére. Kiemelten figyeljünk erre, 


ha egymagunk vagyunk ,az [I": mérjük fel, 





helyét. Talán csak annyi változott, hogy megjelentek olyan 
alkalmazások, amelyekkel kevesebb fáradsággal, rendszere- 
zett és jobban használható adatokat gyűjthetünk a konszo- 
lidálásra jelölt rendszerekről. Amikor pedig nekivágunk a 
feladatnak, akkor használhatjuk például a System Center 
Virtual Machine Managert, hogy fizikai gépeinket vir- 
tuális gépekké konvertáljuk. No de ne szaladjunk ennyire 
előre! Haladjunk nagyjából abban a sorrendben, ahogy a 
konszolidációs folyamat halad! 


Ha szerverkonszolidációra adjuk a fejünket, készüljünk 





fel arra, hogy hosszú ideig nem fogunk tudni látvá- 








nyos technológiai fejlesztéseket felmutatni. Ez a folyamat 
ugyanis hosszadalmas és gyakran nehézkes tervező-szerve- 
ző munkával kezdődik. Legelsőként saját magunkban, illetve az II-n belüli kollégák körében 
kell közös nevezőre, egységes álláspontra jutnunk a virtualizációt illetően. Tanulságos olvas- 
mány a témában a Kusnetzky Group tanulmánya a virtualizációhoz kapcsolódó 10 legfonto- 
sabb mítoszról. Csak a négy legérdekesebb pontot emelném ki ezzel kapcsolatban: 

1. Az én cégem máris készen áll a virtualizáció alkalmazására. 

2. Nincs szükség különösebb szakértelemre az implementációhoz. 

3. Nincs szükség részletes tervezésre, minden megoldható néhány kattintással. 

4. A virtualizáció csökkenti a rendszer komplexitását. 

A négy felvetett kérdést akár egymással összefüggésben is vizsgálhatjuk: a virtualizációs tech- 
nológiák alkalmazása rövid távon egészen biztosan nem csökkenti a rendszer komplexitását, hi- 
szen teljesen új, korábban nem használt technológiai rétegek kerülnek a rendszerbe, amelyeket 
egyrészt meg kell ismernünk, másrészt a felügyeletükhöz szükséges folyamatokat ki kell fejleszte- 
nünk és dokumentálnunk. Hosszabb távon jelentkezhet a komplexitás csökkenése, ha a virtua- 
lizáció egyfajta katalizátorként hat, és ösztönöz bennünket a felügyeleti folyamatok pontosítá- 
sára, jobb összehangolására és a lehető legtöbb feladat automatizálására. Ha többen dolgozunk 


az [Iszervezetben, akkor szükség lehet az egyes munkatársak feladatainak újragondolására és 


[4 


1. ábra. A konszolidáció tervezési folyamata a TechCenteren 


mennyi idő alatt, milyen kisebb lépéseken ke- 
resztül tudjuk elérni a kitűzött célt úgy, hogy 
közben nem hanyagoljuk el az élő rendszere- 
ket sem. Ezen a ponton máris a tervezésnél 
tartunk. Tervezni pedig kötelező! Mégpedig 
több 


szükség lesz egy pénzügyi tervre. Elég nagy 


irányban egyszerre. Mindenképpen 
a valószínűsége annak, hogy a konszolidációs 
folyamatot nem tudjuk véghezvinni pénzügyi 
befektetés nélkül, tehát feltétlenül meg kell 
győznünk azokat a döntéshozókat, akik finan- 
szírozzák terveinket. Meggyőzésükhöz több 
helyről is gyűjthetünk érveket, néhány példát 
a következő fejezetben bemutatok. 

A következő lépés a konszolidációs útiterv: 


milyen gépeket, szolgáltatásokat mozgatok 


Microsoft TechNet 
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virtuális platformra, milyen sorrendben, mi 
lyen módszerrel, és mi a tervem, ha valami 
nem sikerül (ez az a bizonyos gyakran elfe- 
lejtett rolkback plan). E lépések tervezéséhez 
remekül használható a fentebb említett cikk. 
A másik vonulat a hosszabb távú tervezés: 
ha gondot okozott a fizikai szerverek túlzott 
elszaporodása (egyedi feladatokra, hosszabb 
távú koncepció nélküli beszerzések), akkor 
mit fogunk kezdeni az elszaporodó virtuális 
gépekkel? A virtuális gépek olcsók, nem lesz 
meg az a beépített korlát, amit a pénzügyi 
lehetőségek jelentettek a fizikai gépek be- 
szerzésekor. Sőt, virtuális gépek esetén még 
a licencelés is egyszerűbb. Megvannak-e az 
eszközeink a hibriddé vált számítóközpon- 
tunk felügyeletére, van-e eljárásunk a licenc 
követésre? Megfelelően nyilvántartjuk, do- 
kumentáljuke virtuális tárolóinkat (storage) 
és hálózatainkat? Több olyan kérdés, amire 
megnyugtató megoldást kell találnunk, és ez 
még mind mindig csak a tervezés. 

A szakértelem kérdése talán a legegysze- 
rűbb, ezen a területen van ugyanis talán a leg- 
nagyobb motiváló erő: a technológiai érdeklő- 
dés. Aki virtualizációs megoldás bevezetésére 
adja a fejét, azt már valamilyen mélységben 
megragadta a technológia és a benne rejlő 
lehetőség. Szerencsére a bevezetéshez szüksé- 
ges eszközök használata nem túl bonyolult. A 
szakértelem kérdése sokkal inkább a tervezési 
és az üzemeltetésbevezetési fázisban nyer jelen- 
tőséget, ahol rendszerszinten kell gondolkod- 
ni a siker érdekében. Hogy csak egyetlen üze- 
meltetési példát említsek: meg kell változtat 
nunk a javítócsomagok telepítésére vonatkozó 
eljárásainkat. A szokásos eljárás nagy valószí- 
nűséggel használható marad a virtuális gépek 
többségére és a virtualizációba nem bevont 
fizikai gépekre, a virtuális gépeket futtató szü- 
lőpartíciók frissítése viszont jobban szervezett 
eljárást igényel, hiszen amikor ezeket frissít 
jük, a rajtuk futó virtuális gépek szolgáltatásai 
is kiesnek. Ha technológiai szempontból nem 
is, de szervezési szempontból mindenképpen 
összetettebb a feladat. (Értjük már, miért aján- 
lott a Windows Server 2008 Coretelepítés 
mint szülőpartíció?! Kevesebb frissítési ciklus, 
kevesebb fejfájás a szervezés körül.) 

Nézzünk bele néhány fontosabb folyamat 
ba, amellyel a szerverkonszolidáció során ta- 
lálkozhatunk, és ismerkedjünk meg néhány 
olyan eszközzel, ami segíthet a kezdeti fázisok 


nehézségeit legyűrni. 
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Tanuljunk közgazdászul! 
Szó esett róla korábban, hogy nagy valószínű- 
séggel szükség lesz valamennyi beruházásra, 
ha szerverkonszolidációba fogunk. Az üzle- 
ti döntéshozók meggyőzése, támogatásuk el 
nyerése nem könnyű feladat, hiszen nem a sa- 
ját szakmánk fegyvertárából kell érveket ke- 
rítenünk, hanem olyan gazdasági tényekkel 
kell előállnunk, amelyekhez a meggyőzendő 
fél valószínűleg sokkal jobban ért. Hogyan 
keressünk tehát muníciót? Milyen érvekkel 
induljunk pénzügyi források megszerzésére? 
Az egyik lehetséges út a jelenlegi rend- 
szerekben kimutatható erőforrás-pazarlás ki 
mutatása, noha ezzel óvatosan kell bánni, 
nehogy a mi hibánkként vagy hozzá nem ér- 
tésünk jeleként jelenjen meg a tény, hogy erő- 
források állnak kihasználatlanul. Mutassuk 
meg inkább a dolog pozitív oldalát: eddig 
műszaki megfontolások, például biztonsági 
okok miatt külön gépekre kellett telepíte- 
nünk bizonyos alkalmazásokat, ami pazarlás- 
hoz vezetett, mert nem tudtunk a feladathoz 
éppen elégséges hardvert vásárolni, hanem 
csak jóval nagyobb teljesítményűt. Most az 
új technológia lehetővé teszi az erőforrások 
koncentrálását és átcsoportosítását, amellyel 
hosszabb távon beszerzések válhatnak szük- 
ségtelenné. Az érveinket alátámasztó mérési 
adatok összegyűjtése eddig sem volt lehetet 
len, hiszen régóta elérhetők a megfelelő telje- 
sítményszámlálók, amelyekből ezeket kinyer- 
hetjük. Szerencsés esetben készen is kaphat 
juk az adatokat a System Center Operations 
Manager (vagy kisebb cég esetén System 
Center Essentials) jelentéseiből, de mit te- 
gyünk, ha egyik rendszer sincs bevezetve? 
Mielőtt 
kezdünk, nézzünk inkább körül például a 


Microsoft weblapjain. Egy nemrégiben közzé- 


tömeges  performanciamérésbe 


tett ingyenes kis eszköz sok egyéb dolog mel 
lett a szerverkonszolidációhoz szükséges ada- 
tok összegyűjtésében is segíthet. A Microsoft 
Assessment and Planning Toolkit nagyon 
hasznos információkat képes nyújtani például 
Vista-:, Windows Server 2008- vagy Office 
2007-bevezetés előtt, amikor megmutatja, 
melyik eszközünk áll készen az adott szoftver 
futtatására. Szerverkonszolidációhoz pedig 
még a teljesítményadatokat is összegyűjti a 
számunkra. A telepítőcsomag mindössze 50 
megabájt, de a működéshez szükség van egy 
SOL-szerverpéldányra is, ami lehet egy más 


célra is használt SOL valahol a hálózaton, 


CNN NR 


vagy kérhetjük a telepítőt, hogy töltse le és 
telepítse ai SOL Express egy példányát. A te- 
lepítés másik előfeltétele az Office csomagból 
a Word és Excel jelenléte, mert az alkalmazás 
ebben a két formátumban készíti el (makró- 
kon keresztül) a jelentéseit, amelyeket akár 
közvetlenül nyomtathatunk is, ha az angol 
nyelv nem akadály. 

A telepítést követően készítsünk egy olyan 
adatbázist, ahová a szoftver a leltárt és a tel 
jesítményjelentéseket elkészíti, majd állítsuk 
össze a felmérendő gépek listáját. Míg a be- 
vezetési feladatokhoz szükséges lépésekben 
sokféle bemeneti adatforrás között választ 
hatunk (Active Directory, alhálózat, SNMP 
community stb.), addig a konszolidációs fel 
méréshez nekünk kell egy géplistát gyárta- 
nunk. Ezt legegyszerűbben a DNS-rekordok 
listájából generálhatjuk, kihagyva az érdekte- 
len gépeket (például asztali gépek és noteboo- 
kok). Ezzel a módszerrel viszont akár tartomá- 
nyon kívüli gépeket is felmérhetünk, például 
az IP-címük megadásával a listában. A követ 
kező lépésben meg kell adnunk a felméréshez 
használandó jogosultságokat. Célszerű elő- 
ször egy, a legtöbb gépen rendszergazdai jog- 
gal rendelkező fiókot megadni, és azt monda- 
ni, hogy ez mehet minden felmérendő gépre, 
majd megadni a kivételeket (például a nem 
tartománytag gépek rendszergazdaiókjait). 
Használható eredményhez az is szükséges, 
hogy a megfelelő tűzfalszabályok érvényesül 
jenek (WMI, Remote Performance Logging, 
Remote Registry). Ezután már csak meg kell 
adnunk, mennyi időn keresztül szeretnénk 
gyűjteni az adatokat. Az alapértelmezés egy 
óra, ami elég is lehet, ha például a napközbe- 
ni tipikus terhelésre vagyunk kíváncsiak. Ha 
az átlagos terhelést szeretnénk látni, hagyjuk 
futni a felmérést legalább 24 órán át! Az ered- 
mény a korábban említett összegző fájlokban 
jelenik meg. A 2. ábrán a virtualizáció előtti 
átlagos kihasználtsági mutatókra láthatunk 
példát. Ezek azok az értékek, amiket érdemes 
az üzleti döntéshozó figyelmébe ajánlani, il 
letve azt a lehetőséget, hogy például a procesz- 
szorok kihasználtságát 10 százalék alatti érté- 
kekről 40-50 százalék feletti értékre tudjuk 
emelni a virtualizációs technológiákkal. 

A másik két terület, ahol érveket találha- 
tunk a pénzügyi döntéshozók meggyőzésére: 
a villamosenergia-felhasználás és a licencgaz- 
dálkodás. Kezdjük az energiával! Csak pró- 
baképpen kikerestem az egyik hardvergyártó 


A 


E CÍMLAPON 





B 
Pre-Consolidation Utilization Report 
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This report provides details of the current utilization of machines in your network based on performance details collected earlier. The values indicate 


the utilization before each machine is virtualized for consolidation 
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2. ábra. Kiszolgálók terhelésjelentése 


néhány belépőszintű és középkategóriás ki- 
szolgálóját. Az alacsonyabb osztályt tekintsük 
tipikusnak, mint egyedi funkciót ellátó szer 
vereket (ezek amúgy is csaknem asztali PC 
kategóriájú gépek). A középkategóriát jelöljük 
meg mint virtuális gépek futtatására alkal 
mas kiszolgálót, és mindkét kategória esetén 
számoljunk a maximális kiépítettségre vonat 
kozó energiafelhasználással és hőleadással. A 
gép által termelt hővel kissé bonyolult számol 
ni, hiszen a gyártók általában BIU/h mér 
tékegységben adják meg az értéket, amit elég 
nehéz kezelni. Az egyszerűség kedvéért kon- 
vertáljuk át az értéket wattra, és számoljunk 
vele mint többletfogyasztással (hiszen tulaj- 
donképpen a felesleges hő elvezetésére ezt az 
energiamennyiséget valóban be kell vinnünk, 


csak éppen a klímaberendezés oldalán). A 


képlet elég egyszerű: 1000 BTU/h - 293 W. 
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A gyártói műszaki dokumentációra épülő át 
számított adatokat az I. táblázat mutatja. 

Az eredmény egészen érdekes. Ha legalább 
három kisebb teljesítményű gépet össze tu- 
dunk vonni egy középkategóriás kiszolgálóra, 
akkor az energiafelhasználás már csökkent 
hető. Csak egy kis ellenőrzés: a kettes típu- 
sú szerverből három darab 2751 W energiát 
fogyaszt óránként, ha ezeket konszolidáljuk 
a négyesre, ez az érték 2339 Wra csökken, a 
megtakarítás 15 százalék körüli. Egy negyedik 
kettes típusú gép konszolidálása pedig már 35 
százalék feletti megtakarítást jelenthet. 

A szoftverköltségek számításához emlé- 
kezzünk arra a szabályra, hogy a Microsoft 
szerveroperációsrendszerei verziójuktól füg- 
gően tartalmaznak további licenceket virtuá- 
lis gépek operációs rendszereihez. Így a Win- 


dows Server 2003 és Windows Server 2008 


CNN NR 


Standard változatai egy, az Enterprise változa- 
tok négy, a Datacenter változatok korlátlan szá- 
mú további operációsrendszerlicencet tartal 
maznak. Ráadásul csak az aktív példányokkal 
kell számolnunk, amelyek aktuálisan futnak. 
A további számításokban online kalkulátorok 
segíthetnek bennünket. (Figyelem, az árakat 
csak viszonyítási alapként használjuk, a pontos 
adatokért kérdezzük szoftverszállítónkat!) 

A mellékelt képen csak az operációs rend- 
szerek költségét számoltattam ki (B. mező 
- világoskékkel) egy-, két és négyprocesszo- 
ros konfigurációkra, ami a gyakorlatban akár 
négy-nyolctizenhat processzormagot is jelent 
het, hiszen a költségeket fizikai processzorra 
kell számítani. Az eredmény itt is érdekes: 
négy virtuális gép egy egyprocesszoros rend- 
szeren (akár négy processzormaggal) már ol 
csóbb lehet Windows Server Datacenter Edi- 
tion verzióval, mint ha a szükséges Standard 
változatokat vásárolnánk meg. Nem beszél 
ve arról, hogy a Datacenter változat korlát 
lan számú további operációs rendszert enged 
meg, amíg a processzorok száma nem változik 
(ez a verzió ugyanis processzoronként licen- 
celt). Érdemes a kalkulátorokkal néhány , mi 
lenne, ha" játékot eljátszani, hogy aztán a leg- 


gazdaságosabb megoldással állhassunk elő. 


Én túl kicsi vagyok ehhez... 

Gondolkodjunkee szervervirtualizációról, ha 
egészen kis cégnél dolgozunk, ahol kiszolgá- 
lóból is esetleg csak egy van? Amikor először 
tettem fel magamnak a kérdést, akkor szinte 
azonnal rávágtam: nem. Ne erőltessünk egy 


megoldást ott, ahová nem való. Aztán feltá- 
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3. ábra. Webhely a szoftverköltségek számításához 
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madt bennem a kisördög, és arra gondoltam, 
tervezzünk itt is merészen. Iegyük fel, van 
a vállalatunknál egy Small Business Server 
2003 kiszolgálónk. Három-négy éve teszi a 
dolgát a sarokban, néha már bizonytalanko- 
dik a hardvere, fontolgatjuk a cseréjét, hiszen 
már a garanciája is rég lejárt. 

Felmerül az igény, hogy szükség lenne egy 
másik gépre, például egy könyvelési vagy vál 
lalatirányítási szoftver számára. Milyen meg- 
oldások közül választhatunk? Vásárolhatunk 
például két új belépőszintű szervert: a meg- 
szokott SBS-ünket migráljuk az egyikre, a 
pénzügyi szoftvert feltesszük a másikra. Nincs 
is ezzel a megoldással semmi baj, ha csak az 
nem, hogy a szép új processzoraink alig-alig 
dolgoznak 5 százalék feletti teljesítményen. 
Ennél még a legelső gőzmozdonyok is jobb ha- 
tásfokkal működtek a XIX. század közepén. 

Van más lehetőség? Gondoljunk egy meré- 
szet, és mondjuk azt, hogy igen. Vásároljunk 
egy kicsit komolyabb szervert, de csak egyet. 
Ha jól választunk, a hardverköltségben még 
meg is takaríthatunk egy keveset. Célozzunk 
meg, mondjuk, egy négymagos processzort, 
4 GB memóriát és néhány SATA csatolófe- 
lületű lemezt (legyen ebből több, mondjuk 
2x80 GB és 4x250 GB) tartalmazó konfigu- 
rációt. Vegyünk hozzá egy Windows Server 
2008 Standard Edition operációs rendszert a 
64 bites szériából, ami tartalmazza a HyperV 
virtualizációs megoldást. Licencekkel máris 
rendben vagyunk, hiszen a Small Business 
Server 2003licencünk megvan, a Windows 
Server 2008 pedig önmagán felül megenged 
egy további példányt, így a pénzügyi rendsze- 
rünk alá is megvan az operációs rendszer. 

Mielőtt nekifognánk a rendszerek átszer- 
vezésének, készítsünk legalább egy vázlatot 
arról, hogy hová szeretnénk eljutni: lesz egy 
gazdagépünk két virtuális géppel, valahogy 
úgy, ahogy az 4. ábrán látható. 

Ha már látjuk az alapstruktúrát, kezdjük 
el az erőforrások elosztását. Induljunk termé- 
szetesen a gazdagép operációs rendszerével, 
hiszen sok szempontból ez a komponens is 
csak egy előfizető a rendszer erőforrásaira. 
Ha nagyon bátrak vagyunk, telepíthetjük a 
Windows Server 2008-at Server Core tele- 
pítési opcióval, de erre csak akkor vállalkoz- 
zunk, ha járatosak vagyunk ezen a területen, 
és még a HyperV távoli (nem tartományi) 
felügyeletével is boldogulunk. (Ennek kon- 
figurálása elég bonyolult, lásd a hivatkozott 
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blogsorozatot.) Bátorságunk jutalma lehet a 
gazdagép kisebb erőforrásigénye és a keve- 
sebb alkalmazandó frissítés. Akármelyik vál 
tozatot is választjuk, a gazdagép operációs 
rendszerét telepítsük a 80 gigabájtos diszkek- 
ből kialakított RAIDI kötetre. 

A virtuális gépek méretezését kezdjük a 
Small Business Server 2003 irányából. Az 
alap egy Windows Server 2003 R2, 32 bi 
tes architektúrával. A Hyper-V-ben rendelke- 
zünk megfelelő integrációs komponensekkel, 
azt kell csak a kis rajzunkra felvezetni, hogy 
összesen két virtuális processzort adhatunk 
gépünkhöz. Memóriából valószínűleg most 
sem rendelkezünk két gigabájtnál többel, en- 
nél több nem kell a virtuális gépünkbe sem. 
A lemezek konfigurációjánál több választási 
lehetőségünk van: létrehozhatunk egyetlen 
RAID5 kötetet vagy két RAIDI1 kötetet a ren- 
delkezésre álló lemezekből. A két külön kötet 
előnye, hogy az SBS így nem , közösködik" a 
pénzügyi alkalmazással, ha bármelyik virtuá- 


lis gép intenzív lemezműveleteket végez, akkor 
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Az adattárolásra használjunk rögzített mére- 
tű VHD állományt, mert ennek a teljesítmé- 
nye alig marad el a fizikai diszkétől (többek 
között, mert a rögzített méret miatt nem töre- 
dezik). Az induló méret legyen 80 gigabájt, ez 
valószínűleg hosszabb időre elegendő lesz. A 
fennmaradó kapacitást szükség esetén menté- 
sekre használhatjuk, vagy akár újabb VHD ál 
lományt hozhatunk létre rajta, és felcsatolhat 
juk az SBS alá kiegészítő tárhelyként. A végső 
diszkkonfiguráció valahogy így alakulhat. 

A Small Business Server migrálása nem 
könnyű feladat, viszont könyvtárnyi az iro- 
dalma, csak keressünk rá néhány kulcsszóra 
az interneten, és már találunk is néhány alter 
natívát. Ha konzervatív (lés biztonságos) utat 
szeretünk járni, akkor a migráció történhet 
egy biztonsági mentés visszatöltésével a virtuá- 
lis gépbe, vagy választhatjuk a , swing migra- 
tion" technikát, amikor egy ideiglenes (pél 
dául egy PC-n futó) gépet vonunk be ideig- 
lenes tartományvezérlőként, amíg a virtuális 
gépben újratelepítjük az SBS-t. Vállalkozó szel 

leműek kísérletezhetnek blokk 





Vállalat irányítási 
rendszer 





4. ábra. Egy virtuális kisvállalat sematikus felépítése 


legfeljebb a közös lemezvezérlő bizonyulhat 
szűk keresztmetszetnek. Az egyetlen nagyobb 
kötet viszont lehetőséget ad arra, hogy bárme- 
lyik gép tárolókapacitását növeljük szükség 
esetén a VHD-fájlok kiterjesztésével. Hogy a 
virtualizált SBS-kiszolgálónk nagy sebesség- 
gel érhesse el a neki szánt tárolókapacitást, 
most válasszuk azt a megoldást, hogy egy úgy- 
nevezett pass-through diszk formájában ren- 
deljük a virtuális géphez a dedikált RAIDI 
kötetet. A pénzügyi alkalmazásunk virtuá- 
lis gépéhez rendeljünk egy virtuális procesz- 
szort és egy gigabájt memóriát. (A Windows 
Server 2008 operációs rendszerhez rendel 
hetnénk akár négy virtuális processzort is, 
de a kisvállalatoknál szokásos alkalmazások: 
nak általában nincs ekkora igényük, sőt csak 


ritkán képesek több processzort használni). 


szintű lemezmásoló szoftverek: 
kel is, és átmásolhatják az SBS 
kiszolgáló diszkjének tartalmát 
a virtuális géphez rendelendő fi 
zikai kötetre. Ez a megoldás akár 
működhet is, ha a másolás után 
a kötetet a virtuális gépünk IDE 
csatolójához rendeljük. A virtuá- 


lis gép hardvere alapvetően szab- 





ványos, tehát van esélye annak, 
hogy a PlugsPlay pótolja vagy 
lecseréli a hiányzó hardverkom- 
ponenseket, és a gép elindul. Gondosan vi- 
gyázzunk viszont az SBS eredeti lemezére 
(lemezeire), hogy legyen visszatérési lehetősé- 
günk, ha mégsem sikerülne a migráció. 

A HyperV integrációs komponensek a 
megfelelő teljesítményhez "mindenképpen 
kellenek, tehát ha a migráció sikeres (járjunk 
bármelyik úton), ezt a csomagot telepítenünk 
kell. Ezekkel a komponensekkel pedig már 
élvezhetjük a szintetikus hálózati csatoló és a 
többi szintetikus eszköz előnyeit és a VMBus 
nyújtotta" györs kommunikációs " csatornat. 
A migrációhoz képest a pénzügyi rendszer 
,zöldmezős" telepítése már valóságos felüdü- 
lés lesz, viszonylag kevés hibalehetőséggel. 

Somogyi Csaba 
(Csaba.Somogyi(Omicrosoft.com) 
Microsoft Magyarország 
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DELL-EMC HA 


High-Availabiliíty Cluster 


Cluster Bundle 


Teljeskörű DELL-EMC megoldás kis- és középvállalatok informatikai kihívásaira 
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Főbb előnyök 

e magas megbízhatóságú hibatürő megoldás a kis- és 
középvállalatok részére (file kiszolgáló , levelező rendszer) 

e bevizsgált és minősített megoldás 

e. magas megbízhatóságú komponensek 

e egyszerű menedzselhetőség 

e rugalmasan bővítető 

c központi adattárolóba integrált Microsoft file kiszolgáló 

e alap infrastruktúra a Microsoft külső kiszolgálói 
számára (MS Exchange 2007, MS SOL 2008...) 





Microsoft 
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Microsoft Gold és EMC Velocity Partner 
— teljeskörű integrációs és támogatási szolgáltatások — 


Az árak 175 Ft/USD árfolyamig érvényesek és tájékoztató jellegűek, a változtatás jogát fenntartjuk! Az árak a hardver 
installációs szolgáltatásokat tartalmazzák, a további egyéni telepítés-igényével forduljon hozzánk bizalommal! 


Dell l Authortasd service Prowidar 


TARKA Ra ARA aa a A a a ti 








2db PowerEdge PE1950 III (cluster) 
Xeon E5410 2.33GHzZ/2x6MB 1333FSB 

4GB RAM 

2x73GB SAS HDD (Integrated SAS6/iIR RAID Controllef) 

Ologic 0LE2462 Dual-port HBA card 

Microsoft Windows Server 2008 Enterprise (for clustering) w/50 CAGE 


EMC Celerra NS20 IP Storage 

6 x 146GB FC drives 

ISCSI Connectivity License 

Common Internet File System (CIFS) License 

3 Years 24hr Response, 9 to 5 Hardware Maintenance 
Celerra Startup Assistant 

Celerra Manager 

Celerra Automated Volume MAnagement 





(bruttó: 5.998.800 Ft)" 
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ÁAÁLKALMAZÁS- 
VIRTUALIZÁCIÓ 


Már megint virtualizáció? Nem puszta divat ez? És mi az, hogy 


,alkalmazásvirtualizáció"? Nem operációs rendszereket szokás 


virtualizálnig? Nem elég csupán egyfajta virtualizáció? 


rendszerüzemeltető informatikusok többsége minden szándék ellenére az állandó , tűz- 
oltással" foglalkozik: folyamatosan esnek be hozzájuk az újabb és újabb panaszok, hi- 
bajegyek, miközben erejüket megfeszítve és gyakran automatizmus nélkül igyekeznek 
teljesíteni az olyan legitim kéréseket, mint a szoftvertelepítés, a gépcsere, a szoftverfrissítés és 
még sorolhatnánk. A virtualizációs megoldások általában - az alkalmazásvirtualizáció pedig 
konkrétan ebben az írásban - azt ígéri, hogy a tűzoltás mellett már másra is jut idő, mégpedig 
azért, mert a javasolt technológia az elvégzendő tevékenységek számát csökkenti, és emellett 


még az előforduló hibák valószínűsége is kisebb lesz. 


Alapozás 

Az alkalmazásvirtualizáció olyan technológia, amely elválasztja egymástól az operációs rend- 
szert és a rá telepített szoftvert. Ahogy a szerver: vagy hardvervirtualizáció esetén a teljes operá- 
ciós rendszerből, pontosabban azok virtuális lemezeiből egyetlen állomány keletkezik, az alkal 
mazásvirtualizáció is egyetlen állományba zsúfolja a virtualizált szoftvert. Ezt a trükköt persze 
az alkalmazás , nem veszi észre", előttünk viszont, ahogy azt majd látni fogjuk, futurisztikus 


lehetőségek nyílnak meg. 


A Microsoft és az alkalmazásvirtualizáció 

A virtualizáció elvét a telepítendő szoftverekre alkalmazni viszonylag új keletű megoldás. 1999 
júniusában négy ITszakember, Harry Ruda, David Greschler, Stuart Schaefer és Owen Mygsliwy 
megalapította a Softricity nevű céget, s azt tűzték ki célul, hogy a szoftvert úgy lehessen elérni, 
mint ahogy ma az elektromosságot. (Software t Electricity - Softricity) A Softricity első ter 
méke volt a SoftGrid, az első alkalmazásvirtualizációs megoldás. A dotcom-lufi kipukkadását 
a cég túlélte, az ígéretes termék szépen fejlődött, a vállalat nevét felkapták. 

A Microsoft, amely 2003-ban felvásárolta a Connectixet (a Virtual PC és a Virtual Server 
szoftverek gyártóját), egy komplex, az adatközpontban folyó tevékenységek mindegyikére kiter- 
jedő megújítási stratégiát dolgozott ki Dynamic System Initiative (DSD) néven. A kezdeménye- 
zésben kiemelkedő szerepet szánt a virtualizációnak, szinte minden változatának. Így került a 
képbe a Softricity. 2006 júniusában létrejött az egyezség a két cég vezetői között, és a Microsoft 
felvásárolta a Softricityt. 

A SottGrid zászlóshajóterméke lett a később kialakított, előfizetéses jelleggel igénybe vehető 
Microsoft Desktop Optimization Pack (MDOP) szoftvercsomagnak. A fejlesztés természete- 


sen nem állt le, és 2008. nyár közepére várható a legfrissebb, 4.5-ös verzió, immár a SoftGrid 
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név nélkül. Az új termék neve Microsoft 


Application Virtualization 4.5 (MAV 4.5). 


A MAV működési elve és 
komponensei 

A MAV működése négy fő részre osztható. 
Az első fázis a virtuális alkalmazás elkészíté- 
se. Ezt a folyamatot , seguencing"-nek hívják, 
jellegét tekintve egyfajta csomagolás, intelli- 
gens ,pillanatfelvétebkészítés". Azért intelli- 


gens, mert a seguencer - tehát a műveletet 


S oftGrid 
Seguencer 


Microsoft System Center 
Virtual Application Server 





A Segvencer teszi virtvalizálhatóvá az alkalmazásokat 
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végző segédprogram - a kezdeti és végállapo- 
tons túl Tröszt, hogy a virtualizálandó szoft 
ver betöltésekor mely állományokra milyen 
sorrendben van szükség (innen a seguenc 
ing, a ,sorrendbe rakás" kifejezés). Ráadásul 
még olyan műveletek is elvégezhetők, mint 
a Microsoft Updateről való alkalmazásfris- 
sítés, aktiválás stb. Látható, mindez sokkal 
több, mint egy egyszerű különbségképzés. 

A végeredmény egy SET kiterjesztésű ál 
lomány, amely az alkalmazás összes kompo- 
nensét tartalmazza, továbbá még néhány, a 
csomag közzétételéhez szükséges konfigurá- 
ciós fájl. 

A második fázis a publikáció és a szoftver 
eljuttatása a megfelelő eszközre. A MAV a 
regisztrált csomagokhoz adott Active Direc 
tory-csoportoknak ad hozzáférést. Aki egy 
ilyen csoport tagja, az elérheti az alkalmazást, 
mások nem. A publikáció az Application Vir 
tualization Management Serveren végezhető 
el a MAV MMC konzol segítségével. Sok más 
mellett itt állíthatók (opcionálisan) a csoma- 
gokra vonatkozó licencelési szabályok. E funk- 
ció segítségével lejárati időt adhatunk egy cso- 
magnak, meghatározhatjuk az összes lemásolt 
SFIfájl számát vagy éppen az egyidejűleg 
használt szoftverpéldányok mennyiségét. 

Ha a csomagot regisztráltuk, és a meg- 
felelő AD csoportnak kiajánlottuk, a cél 
ba juttatásról az Application Virtualization 
Streaming Server gondoskodik. Ez a harma- 
dik fázis. Bármilyen furcsán hangzik elsőre, a 
szoltver - vagyis most már az SF I-tájl -— úgy 
érkezik, mint egy internetes rádióadás-fo- 
lyam, sőt még a protokoll sem különbözik 
(RISP - Real Time Streaming Protocol, 
TCP 554). Mivel a seguencing fázis során 
az SFIfájlban a szoftverindításnak megfe- 
lelő módon helyezkednek el az állományok, 
az adatfolyam célgépre juttatása során mód 
van csupán az ,éppen elégséges" szoftverkód 
lejuttatására. A gyakorlatban ez azt jelenti, 
hogy az SFI-nek mindössze 20-30 százaléka 
kerül a végfelhasználó gépére, és máris elin- 
dul a szoftver. A koreai súgó meg letöltődik, 
ha majd szükség van rá. 

Eltekintve a furcsának tűnő streaming- 
technológiától, a szoftver lényegében fájlmá- 
solással kerül a desktopokra, ami egyben azt 
az érdekes helyzetet idézi elő, hogy az alkal 
mazás ,azt hiszi", egyes egyedül ,ő" települt 
és fut az operációs rendszeren (pedig nem), 


az operációs rendszer ugyanakkor , azt hiszi", 
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hogy érintetlen, és semmilyen szoftver nem 
került rá (pedig de). 

A negyedik fázis főszereplője a munkaállo- 
másokra telepített MAV-kliens, amelynek há- 





SystemGuard" EnvironmentA SystemGuard" Environment B 


Application 
fa 


Application 
5. 





Data System Services Configurations 
(Profile and (Windows services, (Registry, .ini files, 
documents) COM, OLE, printers, DLLs, etc.) 


fonts, cut $. paste) 


Operating System 











A virtuális alkalmazások nem zavarják egymást 


romféle feladata van. A MAV-:szoftverpubliká- 
ciókat észleli, és az operációs rendszert ennek 
megfelelően konfigurálja. Ha egy felhasználó 
jogosult egy adott virtuális alkalmazás futta- 
tására, akkor a MAV-kliens gondoskodik az al 
kalmazást reprezentáló parancsikonok, környe- 
zetérzékeny menük, fájlasszociációk megjelené- 
séről, mintha az alkalmazás már a gépen len- 
ne. Mikor aztán a felhasználó kettőt kattint az 
alkalmazás ikonján, a MAV-kliens adatfolyam- 
ként letölti a streaming-szerverről a szükséges 
mennyiségű kódot a desktopra, pontosabban a 
MAV-cache-:be, és a programot elindítja. 
Végül a MAV-kliens felelős a virtuális 
környezet biztosításáért. Szemben a hardver- 
virtualizációval, itt nincs szó emulációról. 
A MAV-kliens figyeli a virtuális alkalmazás 
rendszerhívásait, és meghatározott hívások 
esetén átirányítja azokat. A virtualizált alkal 
mazás az operációs rendszer és a seguencing 
során rögzített rendszerparaméterek egymás- 
ra vetített változatát látja, anélkül, hogy ezt 
az ,egymásra vetítést" érzékelné. 
A fenti módon a következő komponensek- 
re való hivatkozást lehet átirányítani: 
x Fájlok (rendszerfájlok is!) 
a Registrykulcsok és -értékek 
a Betűállományok 
am .iniállományok 
a COM/DCOM-objektumok 
n Szolgáltatások 
a Névterek 


an Szemaforok, mutexek 


— Xx 
S 


A felsorolt rendszerelemek elérésekor a 
MAV-kliens átirányíthatja a hívásokat az 
SFI-fájlba. Az átirányítás igény szerinti. Ha 
például az alkalmazás telepít magával egy be- 
tűkészletet, akkor futáskor úgy látja, mintha 
az adott desktopon fent lenne a betűkészlet. 
Amikor ténylegesen meghívja valamelyiket, 
akkor a MAV-kliens - az alkalmazás számá- 
ra nem észlelhető módon - átirányítja az 
SFLfájlba, ahonnan a készlet betöltődik. 
Hasonlóan működik a többi átirányítás is. 
A művelet olyan gyors, hogy a futás teljesít 
mény-vesztés még az 1 százalékot sem éri el. 

Természetesen nem minden műveletet 
kell átirányítani. Az SFI-fájlban nem találha- 
tó objektumok (rendszerfájlok: és szolgáltatá- 
sok, COM-névterek stb.) rajta vannak a gaz- 
dagépen, amit az alkalmazás természetes mó- 
don, változtatás nélkül képes elérni. Éppígy 
működnek a lemezműveletek: a virtualizált 
WINWORD.EXE a valóságos mappákból 
valóságos dokumentumokat nyit meg, sőt 
a felhasználó beállításait is a valóságos pro- 
filjából tölti be. Fontos hangsúlyozni, hogy 
a virtualizált alkalmazások helyben futnak, 
éppúgy, mintha telepített alkalmazások len- 
nének. Szépen látszanak például a feladat 
kezelőben. 

Itt jegyezzük meg, hogy bár működhet/elk 
indulhat egy alkalmazás az SFT-fájl 20-30 szá- 
zalékának letöltésekor is, ez nem zárja ki azt, 
hogy az SET t teljes egészében letöltsük, sőt 
erre szükség is van kapcsolat nélküli üzem- 
mód esetén. Vagyis, ami nagyon fontos, a 
MAV képes futtatni a virtuális alkalmazá- 
sokat hálózat nélküli állapotban. (Sőt, még 
nem 100 százalékos letöltöttség esetén is, de 


ekkor persze rizikós egy-egy funkció elérése.) 


A MAV technológiai korlátai 


Nem lenne teljes a kép, ha nem mondanánk 
el, milyen korlátai vannak a fenti megoldás- 
nak a technológia jelen állása szerint. 

Nem minden alkalmazás virtualizálható. 
Ökölszabályként azt érdemes megjegyezni, 
hogy a kernel módú komponenst, eszköz- 
meghajtót tartalmazó szoftverek nem csoma- 
golhatók be. Ebbe a kategóriába tartoznak 
az antivírusszoftverek vagy a CD/DVDíró 
programok. Ugyancsak nem virtualizálhatók 
a Comt komponenseket használó szoftve- 
rek, a hardverhez kötődő szoftverek (például 
a gép MAC-címét ellenőrző megoldások). 
Teljes bizonyossággal csak az SFI-fájl alapos 


Microsoft TechNet 
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tesztelése után mondható ki, hogy az alkal 
mazás virtúalizálható. 

Végül érdemes megemlíteni, hogy a 4.5-ös 
megoldás még csak 32 bites változatban érhe- 


tő el, tehát a 64 bites terminálszerverek nem 


lehetnek MAV-kliensek. 


Felhasználási területek 

A MAV-komponensek rövid áttekintése után 
nézzük meg, hogy ez a viszonylag egyszerű 
technológia milyen lehetőségeket teremt az 
üzemeltetők számára. Az itt felsorolt felhasz- 
nálási területeket ne tekintse az olvasó teljes 
listának, hiszen csak a fantázia szab határt az 
alkalmazhatóságnak. 

Gyors alkalmazáskiajánlás (provizioná- 
lás). A már meglévő csomagok esetén a ki 
ajánlás egy Active Directory-csoporttagság 
beállítására egyszerűsödik. Amint a csoport 
tagság változását érzékeli a MAV-kliens, az al 


kalmazás ikonja, hivatko- 


A megfelelő idő elteltével pedig az Office 
2003 eltávolítható. 

Teljes verzióváltás a maradék szoftverek 
megtartásával. Az előző példa fordítva is mű- 
ködik. Telepíthetünk hagyományos módszer- 
rel Office 2007-et, és ha például egy részlegen 
egy régi Access 97-re írt partizánszoftvert fut 
tatnak, annak virtualizálásával megoldható 
az új vállalati Officecszabvánnyal nem kom- 
patibilis alkalmazások megőrzése is. 

Eltérő beállítások alkalmazása. Az Inter- 
net Explorer maga nem virtualizálható, de 
a beállításai igen. Így lehetséges például há- 
zirenddel minden ActiveX-vezérlőt letiltani, 
de egy olyan virtuális példányt mégis el lehet 
indítani, amelybe becsomagoltunk egy, álta- 
lunk fontosnak ítélt vezérlőt. 

Terminálszerver- (Citrix) silók megszün- 
tetése. Az inkompatibilis alkalmazások ko- 


moly méretezési problémát jelentenek a ter 





zásai, fájlhozzárendelései 


megjelennek a felhaszná- 





ló számára. Application 
Virtualization 
S 
Gyors, rugalmas , tele- EEZ ETET Management 
Windowsd) Vele Service 


pítés". A virtualizált al 


application 
kalmazást nem kell telepí- 
teni. Amikor a felhaszná- 
ló elindítja, magától letöl 
tődik és elindul. 
Inkompatibilis alkal 


mazások — párhuzamos 


VECD 


futtatása. Az átirányítási 
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server 


technológia lehetővé te- fljerosáít ágálásállon 


szi, hogy minden VIrtua- Virtualization Clients 
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kívánta környezetet lássa, 
ezáltal párhuzamosan , te- 
lepíthetővé" és futtathatóvá válnak egymás 
létezését kizáró szoftverek is. Két eltérő Java 
virtuális környezetet igénylő szoftver a maga 
Java futtatójával összecsomagolva párhuza- 
mosan futhat, de ez a helyzet két (sőt akár há- 
rom vagy négy!) Officeverzióval is. 

Gyors és biztonságos verzióváltás. A fen- 
ti jellemző kihasználásával egy alkalmazás 
újabbal való lecserélése sokkal gyorsabbá, 
és - ami még ennél is fontosabb - bizton- 
ságosabbá válhat. Egy hagyományosan te- 
lepített Office 2003 mellé gond nélkül ki 
ajánlhatunk egy virtualizált Office 2007-et. 
Probléma esetén a gépen maradt korábbi 
verzió használható, az Office 2007 biztosan 
nem rontja el a COM/DCOMtnévtereket. 
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Teljes kiépítésű rendszer 


minálszervereknél. A hagyományos megoldás 
általában az, hogy kéthárom ún. silót (szer- 
vercsoportot) hoznak létre: egy-egy silóban 
csak olyan terminálkiszolgáló található, ame- 
lyik azonos alkalmazásokat futtat. Más silók- 
ban más, az előző silóval nem kompatibilis 
alkalmazások futnak. Ez a szerverek számát 
jócskán növeli. A MAV lehetővé teszi, hogy 
a silókat megszüntessük, és csupán egyetlen 
csoportot hagyjunk meg úgy, hogy az inkom- 
patibilis alkalmazásokat virtualizáljuk. 
Többgépes/barangoló felhasználók. Az 
MAV a felhasználókhoz rendeli a szoftvere- 
ket. Mivel az AD-csoporttagság minden gépen 
azonos, ezért MAV-kliens esetén az alkalmazá- 


sok automatikusan követik a felhasználót. 
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Gépcsere. Ha a személyes beállítások map- 
paátirányítással központilag letölthetők, a 
végfelhasználói munkaállomások állapot nél 
külivé válnak, vagyis a gépek cseréje, tarta- 
lékgépek átmeneti kiadása lényegében nem 
igényli a rendszergazdák közreműködését, 
miközben minden felhasználó mindig ugyan- 
olyan környezettel találkozik 

A többdesktopos üzemmód megszünte- 
tése. Az inkompatibilis alkalmazások prob- 
lémájának egyszerű megoldása az adott fel 
használóknál a két (három?) PC megjelenése, 
terminálszerver alkalmazása, VDIrmegoldás 
implementálása. Ezek a megoldások teljes 
mértékben kiküszöbölhetők. Meglehetősen 
furcsa, de ebből egyenesen következik, hogy 
az alkalmazásvirtualizációval akár a felhasz- 
nálói gépek száma (és azok minden költsége) 
is csökkenhet. 

Kevesebb operációsrendszer-lemezkép. A 
telepített, de egymást kizáró alkalmazások 
jócskán okoznak többletfeladatot az operá- 
ciósrendszerlemezképek létrehozásánál és 
karbantartásánál. Elvileg minden egyes te- 
lepített komponenst minden mással le kell 
tesztelni kompatibilitás szempontjából. Ez a 
regressziótesztelés annál hosszabb folyamat, 
minél több szoftverről van szó, de csak így le- 
het bizonyosan hibátlan lemezképet előállíta- 
ni. A MAV lehetővé teszi, hogy ad absurdum 
egyetlen felhasználói szoftvert se telepítsünk 
az operációs rendszerre. Akár egy több ezer 
PC-vel rendelkező szervezet is elboldogulhat 
egyetlen, jól kialakított lemezképpel. A költ 
séges és hosszadalmas regressziótesztelés tel 
jes egészében elhagyható. 

Active Update-technológia. Még nem 
esett róla szó, de a seguencing támogatja 
a csomagok frissítését. Egy már elkészített 
Office 2007-csomagot újra meg lehet nyitni, 
frissíteni SPLre, majd lezárni. A menedzs- 
mentkonzolon megadható, hogy az új cso- 
mag az előző frissítése. A felhasználó a már 
elindított alkalmazást gond nélkül használ 
hatja, a következő indításkor pedig - hip- 
hip, barbatrükk — márraz oP lgyelrírissített 
csomag indul el. Iehát nem 3000 Office-t 
kell frissíteni, hanem csak egyet! (A frissítési 
technológia ennél még sokrétűbb, de a cik- 


ken belül ezt nem taglaljuk.) 


Felmerülő problémák 
Ez idáig szép és jó. Öreg rókákat azonban 


nem vakít el talmi csillogás: a MAV - bármi 


Le 
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lyen sok problémát old is meg - számos kér- 
dést generál. 

Mindenekelőtt mi lesz az olyan gépekkel, 
amelyek sohasem találkoznak a hálózattal? 
Eldugott helyen üzemelnek, vagy éppen biz- 


tonsági okokból sohasem kerülnek fel oda. 
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Egyszerű kiépítésű rendszer 


Hogyan lehet ezután szoftverleltárt készíte- 
ni! Ha egy alkalmazás pusztán egy SFLállo- 
mány, akkor sem a Control Panel Programok 
részében, sem a fájlrendszer átfésülésével, 
sem a regisztrációs adatbázis böngészésével 
nem lehet megállapítani, milyen alkalmazá- 
sok vannak ténylegesen egy gépen. 

Mi: lesz a gépeket megcélzó szoftverdisztri- 
búciós mechanizmusokkal? Nem telepíthe- 
tünk géphez kötődő szoftvert? 

Nirársorsaa WSUS-nak! 

Végül - és talán ez a legnehezebb kérdés 
- ha nekünk van már egy jól bejáratott szoft 
verdisztribúciós mechanizmusunk, akkor azt 
most le kell cserélnünk? El kell dobnunk 
mindazt, amit eddig felépítettünk? (A szoft 
verterítő alkalmazások megnevezése angolul 
, Electronic Software Distribution ", és az ESD 
rövidítés használatos, mi is ezt követjük.) 

Ahhoz, hogy a fenti kérdésekre megnyug- 
tató válaszokat adhassunk, meg kell ismer- 
nünk a MAVé-építőelemekből létrehozható 


szoftverterítési modelleket. 


MAV-architektúrák 


MAViinfrastruktúrát a négy fázis alkotó- 
elemeiből építhetünk. Csak ismétléskép- 
pen: Csomagolás (Seguencing) - Közzététel 
(Publishing) - Célba juttatás (Streaming) 
cö Futtatás MadocAine and Ttúnnine) AA TÁZT 


sokat megfelelő szoftverkomponensek támo- 
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gatják. A MAV 4.5-től ezek a komponensek 
külön-külön felhasználhatók. Ezek alapján 
három alapstruktúra képzelhető el. 

Teljes kiépítés. Minden komponenst fel 
használunk, ahogy azt a fentiekben leírtuk. 
Ezt a modellt többnyire az adatközpontok 
követik. 

Egyszerű kiépítés. A csomagolás után ki 
hagyjuk a publikációt, és csak a streaming-ki- 
szolgálót meg a klienst használjuk. 

A megoldás előnye, hogy sem AD-re, sem 
SOL-kiszolgálóra nincs szükség (ideális meg- 
oldás távoli telephelyek esetén), viszont le 
kell mondanunk a szoftverhasználat méré- 
séről, és gondoskodni kell a publikálásról. 
Utóbbira jó lehet a központban felállított 
MAV Management Server, vagy megoldható 
scripttel, de többnyire az ESD-szoftverek vég- 
zik majd el. 

Szerver nélküli kiépítés. A MAV 4.5-ös 
csomagolója az eljárás végén felajánlja, hogy 
az elkészült MAV-csomagot még egy MSI-ke- 
rettel is körbeveszi. A funkció opcionális, de 
a szerver nélküli kiépítésnél nagyon hasznos. 
Az MSlLállomány CD-re, DVD-re másolható, 
és bármikor ,telepíthető", sőt remekül fel 
használhatják azok az ESD-termékek, ame- 
lyek nem ismerik az alkalmazásvirtualizáció 
fogalmát. Az MSI-keret összesen két feladatot 
lát el: a MAV-csomagot 100 százalékban be- 
tölti a MAV-kliens cache-ébe, továbbá egy 
regisztrációs kulcs segítségével megjelenteti 
a szoftvert a Control Panel , Programok" ré- 
szében, hogy a szoftverleltár helyes adatokat 
mutasson. Mindez azonban nem telepítés, a 
szoftver továbbra is virtualizált, és élvezi a 


MAV-kliens hordozta előnyöket: az egymás- 
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sal inkompatibilis alkalmazások futtatását, 
az intakt operációs rendszer megőrzését stb. 

Az opcionális MSLkeret egyébként nem 
a 4.5-ös verzió újdonsága: 2007 decemberé- 
ben a SoftGrid 4.2-höz jelent meg egy ingye- 
nesen letölthető segédprogram, amely még 
különálló módon, de a fenti funkcionalitást 
biztosította. 

Az MSI.keret, ahogy láttuk, átvágja a gor- 
diuszi csomót. Ha egy II-szervezet csak a 
kliensen tapasztalható alkalmazásvirtualizá- 
ciós előnyökre vágyik, de meg akarja tarta- 
ni a hagyományos ESD-rendszerét, és nem 
szeretne dupla disztribúciós mechanizmust, 
ezt könnyűszerrel megteheti. Az integráció- 
nak azonban van ennél magasabb szintje is: a 
System Center Configuration Manager 2007 
R2 egyik legfontosabb képessége a MAV-val 


való igen szoros együttműködés. 


SCCM 2007 R2-integráció 
A MAV és az SCCM együttműködése négy 
területre terjed ki. 
1. Csomagolás és alkalmazásdisztribúció 
2. Csomagterítés az SCCM-hirdetéses (ad- 
vertisement) mechanizmusával 
3. Alkalmazásíuttatás 
4. Leltár és jelentéskészítés 
Az SCCM 2007 RZ2 szerver: és kliensoldali 
komponensei is , ismerik" a MAV 4.5-öt. Ha 
például előzőleg az Application Virtualization 
Streaming Servert telepítettük, egy disztri- 
búciós ponton tulajdonságként . állítható, 
hogy a kliensekre hagyományos módszerrel 
vagy streaminggel juttassa el a csomagokat. 
(Olyasfajta integráció ez, mint a WSUS- és a 
WDSintegráció: az SCCM az eredeti szoft 
vert további képességek 
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meri a MAV-os , kollégá- 
ját, regisztrálja magát, 
és intelligensen eldöntik, 
melyik csomag letöltését 
melyik kliens hajtja vég- 
re. Sőt! Az is előfordul 
hat, hogy az MSLvel ke- 
retezett virtuális alkalma- 
zásokat az SCCM-kliens 
tölti le (hagyományos mó- 
don), de azután a MAV- 
cache-be másolja, az indí- 


tásról pedig a MAV-kliens 





Szerver nélküli kiépítés 


gondoskodik. 
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Az integráció fő célja az, hogy a MAV-inf 
rastruktúrából az aktuális igényeknek megfe- 
lelően mindig annyit használjunk, amennyi- 
re szükség van. 

A szerverek vonatkozásában a legizgalma- 
sabb együttműködési terület kétségkívül a 
disztribúciós pontok integrációja. A virtuális 


alkalmazások meghirdetésekor meghatároz- 


tett SFCLt, ai SCCM bináris deltareplikáció- 
val csak a különbséget replikálja át előbb a 
telephelyekre, majd a disztribúciós pontok 
ra. A frissítésről a munkaállomások akkor 
értesülnek, amikor a rendszergazdák újra- 
futtatják az SCCM-hirdetést. Ha a szoftvert 
a disztribúciós pontról indítjuk (Streaming 


Delivery), az új verzió azonnal elérhető. A 
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Integráció a Configuration Managerrel 


hatjuk, hogy a kliens milyen módon indít 
sa a virtuális alkalmazást. Ha , Stream from 
DP" (Streaming delivery) opciót állítunk be, 
a felhasználói asztalra telepített ikonok a 
disztribúciós pontra muűútatnak, cs az oF[ 
állományok onnan is indulnak. (Hacsak le 
nem töltődtek korábban 100 százalékban.) 
A , Download and Execute" (Local Delivery) 
ezzel szemben a parancsikonokat mindig a 
helyi MAV cache-ben lévő, 100 százalékig le- 
töltött SFI-állományokra irányítja. 

Az SCCM funkcionalitását felhasználva a 
MAV-kliens mindig a legközelebbi disztribú- 
ciós pontról indítja a letöltést. Ehhez ,csu- 
bat atta van szükség hooy az alkalmazások 
indításakor az SCCM-kliens lekérdezze az 
SCCM menedzsmentpontszervert, amelyik 
a telephelynek megfelelő legközelebbi diszt 
ribúciós pont. A kapott eredmény alapján az 
SCCM-ügynök módosítja a MAV-kliens pa- 
ramétereit, amely azután a helyes streaming- 
képes disztribúciós ponthoz fordul. 

De nemcsak a szoftverdisztribúció, ha- 
nem a szoftverfrissítés is integrált. Miután 


a MAV-seguencerrel elkészítettük a frissí- 
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helyi futtatás (Local Delivery) opciónál a kü- 
lönbség BITS-szel kerül a MAV cache-be, és 
csak akkor indul el a frissített verzió, amikor 
a teljes csomagfrissítés befejeződött. 

Az SCCM 2007 R2-nek már nem kell az 
MSI keretekre hagyatkoznia, amikor a vir- 
tuális alkalmazásokat szeretné számba venni. 
A MAV 4.5 egy új kliens WMLproviderrel 
rendelkezik, így már le lehet kérdezni a cache 
tartalmát, a letöltött programokat, azok ver- 


zióját, használatukat stb. 


Licencelés 

Számtalan alkalmazásvirtualizáció témájú 
megbeszélés után biztosan állíthatom, a leg- 
nagyobb kavarodás a fejekben a licencelés 
körül alakul ki. A villámgyors szoftverdiszt 
ribúció és gyors alkalmazáseltávolítás miatt 
úgy tűnhet, mintha a MAV alapvetően be- 
folyásolná a megvásárolandó szoftverek szá- 
mát. Minderre még ráerősít a termékben ta- 
lálható licencelési funkció, a csomagok hasz- 
nálatának időbeli korlátozása. Öntsünk tisz- 
ta vizet a pohárba ezzel kapcsolatban. 


Az első és legfontosabb szabály, hogy a 
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MAV egy technológia, tehát semmilyen 
módon nem változtatja meg a becsomagolt 
szoftverre vonatkozó licencelési szabályokat. 
Konkrétan: ha a licenc egy adott géphez kö- 
ti a szoftvert (tipikusan OEM-konstrukciók), 
akkor a felhasználó alapú disztribúció meg- 
sérti a licencjogokat. Ha viszont a licencszer- 
ződés konkurens használatra szól, vagy adott 
felhasználóhoz kötött, akkor a MAV kifejezet 
ten segíti a konstrukció betartását. Jogi szem- 
pontból ugyancsak problémamentes azoknak 
a szoftvereknek a használata, amelyek egy 
teljes telephelyre vagy a teljes vállalatra vonat 
koznak. (A Microsoft Enterprise Agreement 
tipikusan ilyen.) A MAV az ilyen konstrukció- 
kat korlátlan (Unlimited) típusnak ismeri. A 
szoftverhasználatról gyűjtött statisztika azon- 
ban még ekkor is hozzásegítheti az [I-szerve- 
zetet, hogy a licencköltségeit csökkentse. 
Külön megér néhány mondatot a MÁV li 
cencelése is. A termék önmagában nem érhe- 
tő el, hanem ahogy a cikk elején már említet 
tük, a Microsoft Desktop Optimization Pack 
(MDOP) része, egyik komponense. Maga az 
MDOP egyéves előfizetéses konstrukcióban 
vásárolható, de csak az olyan szervezetek 
számára, amelyek érvényes desktop-írissítés- 
védelemmel (Desktop Software Assurance, 
vagy Desktop SA) rendelkeznek. A MAV- 
komponensek külön nem igényelnek licen- 
cet. Amennyiben a munkaállomások lefe- 
dettek MDOPicenccel, szerverkomponenst 
akárhányat telepíthetünk. Az MDOP-icenc 
(ény az SEEN Z007Z0RZ integtació esetén 


is érvényes. 


Zárszó 
Az alkalmazásvirtualizáció legalább akkora 
potenciállal rendelkezik, mint a nála ismer- 
tebb hardvervirtualizáció, és éppúgy gyöke- 
resen átalakítja az üzemeltetők életét. A vál 
tozás- és konfigurációkezelési (change and 
configuration management) feladatokat tel 
jes mértékben újra kell gondolni. Sajnos? 
Szerencsére? A választ nem nekem kell meg- 
adni. Egyben viszont bizonyos vagyok: a ma 
végfelhasználója borzasztóan kiábrándult az 
informatikából. Lassúnak, rugalmatlannak, 
nyögvenyelősnek tartja. Az alkalmazásvirtua- 
lizáció visszaadhatja a hitet a rendszerüzemel- 
tetőknek és felhasználóknak egyaránt: lehet 
Itt sokkal jobban is csinálni. 
Lepenye Ilamás 
(tamaskemicrosoft.com) MCSE, Microsoft Magyarország 
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A Windows Vistával érkező rugalmas 











telepítési lehetőségek kis fejtöréssel 
lényegében bármelyik Microsoft operációs 
rendszer tömeges telepítését lehetővé teszik. 


mikor 2001-ben először hallottam hálózaton keresztüli operációsrendszer-telepítésről, 
nem tulajdonítottam neki túl nagy jelentőséget. Az akkoriban még csak stabil 10 mega- 
bites hálózati kapcsolaton keresztülbpumpálni 23 gigabájt mennyiségű adatot? Badarság, 
kinek van erre szüksége? Az operációs rendszernek telepítő CD-n a helye. Bizony, néhány évvel 
később meg kellett állapítanom, hogy immáron pont telepítőlemezt használok a legkevésbé a 
feladat elvégzéséhez. Ezzel a cikkel az a szándékom, hogy a rengeteg új fogalom és eszköz közül 
kiválaszthassuk azt, amellyel leghatékonyabban elérhetjük célunkat! A májusi Technetkon- 
ferencián hallottakat most kiegészíteném egy általános előkészítői leckével, illetve jó néhány 
hasznos praktikával, ötlettel. Sok kisebb-nagyobb, egyszerűbb-bonyolultabb eszköz áll rendelk 


kezésre, a választást a cél határozza meg, tehát nem kell feltétlenül mindet használnunk. 


Az etalonpéldány 

Szoktam még donor, vakpéldány, vagy mesterpéldány néven is hivatkozni arra az operációs 
rendszerre, amely lényegében egy univerzális, sok szempontnak megfelelő alaprendszer, a to- 
vábbi telepítések alapanyaga. Létrehozásakor az a cél, hogy minél kevesebb manuális beavatko- 
zással tudjuk , személyre", vagyis számítógépre szabni beállításait. Mesterpéldány készítésekor a 
tőbb szempontok jellemzően a különböző gép-(hardventípusokra történő felkészítés, a fonto- 
sabb alkalmazások előtelepítése, licenctípusok meghatározása stb. Ez a fázis a legidőigényesebb 
feladat, de ne sajnáljuk az időt tesztelésére, rengeteg bosszúságot és főleg időt takaríthatunk 
meg később egy jó etalonpéldánnyal. A sysprep eszközzel , konzervált" operációs rendszer ter- 
jesztése után (vagyis az egyedi információktól megfosztott operációs rendszert valamely módon 
kimásoljuk a telepítendő gépre) a közel 10 perces, ún. mini-setup segítségével életre kel. Egyedi 
paraméterek megadása után (például gépnév, sorozatszám, tartományi tagság) PNP-ellenőrzést 
hajt végre (tehát nem nekünk kell bíbelődnünk gépenként esetlegesen egyedi meghajtóprog- 
ramok telepítésével, természetesen csak akkor, ha megfelelően felkészítettük erre az etalonpél 
dányt). Lényegében ezután azonnal működőképes lesz a rendszerünk, hisz a tesztelés részét már 


letudtuk, amikor elkészítettük a vakpéldányt. Itt kell megjegyeznem, hogy ha nincs szükségünk 
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egyedi paraméterekre, megtehetjük, hogy élő 
operációs rendszerről készítünk másolatot, 
ekkor beszélünk a ,klónozás" folyamatáról, 
hiszen az operációs rendszer , SID"je, vagyis 
egyedi azonosítója ekkor minden újonnan te- 
lepített gépen ugyanaz lesz, és ez tartományi 


környezetben problémákat okozhat. 


Válaszállomány(ok) 

Míg az XP ötféle válaszállományt használt, 
addig a Vista mindössze egyet (unattend. 
xml]). Ezeket a fájlokat arra találták ki, hogy 
meghatározhassuk egyedi beállításainkat, il 
letve azért, hogy mennyire szeretnénk a te- 
lepítési folyamatot automatizálni (értsd: mi- 
kor, mennyit kell manuálisan konfigurálni). 
A Vista sokkal több lehetőséget ad erre (több 
mint 300-féle érdemi beállítási lehetőség), 
eligazodni a rengeteg lehetőség között a Win- 
dows System Image Manager (WSIM) segít. 
A kimenet egy szöveges állomány, amelyet 
akár egy notepaddel is módosíthatunk, te- 
hát látható: ha további eszközöket is beve- 
tünk a válaszállomány manipulálására (pél 
dául programozott stringcserét), akkor a kézi 
beavatkozást gyakorlatilag a számítógép ki- és 
bekapcsolására korlátozhatjuk. 

Hol találjuk a válaszfájlszerkesztő progra- 
mot? A Vista esetén a WSIM az Automated 
Installation Kit (AIK) része, amely egy ingye- 
nesen letölthető szoftver- és dokumentáció- 
gyűjtemény. 

Íme egy részlet egy Vistához készült unat 
tend.xml-ből, azaz konkrétan arról, hogyan le- 
het automatikusan beléptetni tartományba a 


SYSPREP-pel konzervált operációs rendszert: 


Identification 
cCredentialsz 
cDomain— wds.local c/Domain— 
c Password Win2008 €/Password— 
cUsername- administrator €/Username— 
c/(redentialsz 
az JoinDomain— wds.local C/JoinDomain— 
€/ldentification— 


Windows Image format (.WIM) 

A Vista új telepítő fájlformátuma, a tömö- 
rített WIM-fájl alkalmas saját etalonpéldá- 
nyaink tárolására is. Valójában teljesen 
mindegy, mit tárolunk ebben a fájl alapú 
lemezképtároló állományban, tehát a sys- 
prep segítségével konzervált vagy csak úgy 


röptében másolt, , klónozható" más verziójú 
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operációs rendszer éppen úgy megfér benne 
egymás mellett, mint ahogy pusztán halott 
adatot tároló (például profilkönyvtárak, vir- 
tuális gépek) partíciók is. Az ,egymás mel 
lett" úgy értendő, hogy a WIM formátum 
indexek segítségével független partíciókat tá- 
rol egyetlen WIM fájlban. Ez lehetővé teszi, 
hogy egy állomány csak először, első alka- 
lommal tárolódjon fizikailag (single instance 
store), ezután, ha egy másik partíció rögzí- 
tésekor ez az állomány ismét tárolódik, már 


csak egy hivatkozás készül rá. Iehát egy-egy 


Lab Environment 
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faster 
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Jellemzőbb formája az automatizált telepí- 
tésnek, ha az AlKdokumentáció segítségével 
létrehozunk egy Windows Preinstallation En- 
vironment (WinPE) lemezt, majd ezzel boo- 
toljuk be a célgépet. A WinPE igen sokoldalú 
megoldás, és van például 64 bites változata 
is. Bár a kezelőfelülete többségében mindösz- 
sze egy parancssor, mégis képes USB 2.0-esz- 
közöket kezelni, hálózati kártyán keresztül 
kommunikálni, dinamikus lemezt kezelni. 


Sőt, mivel eszközvezérlő bővítési lehetősé- 


günk is van a PEIMG (AIK, micsoda meg- 


Factory Floar 


Destlnatan 
Computerz 


Ahogy a nagykönyvben meg van írva — a valóságban sokkal több lehetőségünk van 


újabb partició hozzáadásakor tizikatlagsésak 
a különbség kerül bele a (WIM fájlba, emiatt 
adattárolási szempontból a WIM igen haté- 
kony formátum. 

A WIM-ben tárolt lemezképeinket az 
IMAGEX.EXE program segítségével tudjuk 
kezelni (ami ugyancsak az AIK része), bele- 
értve az újabb lemezképek hozzáadását vagy a 
meglévők módosítását is. Ugyanezzel a prog- 
rammal lehet visszaállítani a tárolt lemez- 
képeket, de erre lesznek még további lehe- 


tőségeink. 


.WIM-tartalom terjesztése 

1. — fapados, 

ám hatékony módszerek 

Ha már rendelkezünk terjeszthető operációs 
rendszerrel, valami módon a WIM állomá- 
nyunk tartalmát fel kell másolnunk a cél 
gépre. Nos, erre elég sokféle lehetőségünk 
van, és a cél fogja meghatározni a módszert. 
Néha megfelel, ha egy USB-csatlakozóval a 
célgép merevlemezét csatlakoztatjuk ahhoz 
a PC-hez, ahol a célpartíciót elkészítjük, ak- 
tiváljuk, megformázzuk, majd az IMAGEX 
/APPLY paranccsal az etalonpéldányt kimá- 


soljuk a végleges helyére. 
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lepetés!) program segítségével, bővíthetjük 
a kezelhető hardverek körét is. A WinPE-t 
atta találták ki hogy fájlokat másolgassunk 
teljesen üres vasakra. (Érdemes megjegyezni: 
ezt a 200 megabájtnyi operációs rendszert 
rávehetjük, hogy közvetlenül merevlemezről 
is elinduljon, de ez inkább perverzió, mint 
alapfelhasználás.) Ezután az IMMAGEX már 
ugyanolyan körülmények között használha- 
tó, mint az előző példában. A .WIM állo- 
mány tehát ugyanúgy tárolható egy USB-s 
merevlemezen, mint egy hálózati megosztá- 
son, így a szükséges etalonpéldányt, illetve az 
egyediséget elérő válaszállományt felmásol 
hatjuk a célgép merevlemezének gyökerébe 


(vagy éppen RAIDO tömbjére). 


.WIM-tartalom terjesztése 

2. — szolgáltatással támogatott 

Az előző bekezdés végén utaltam rá, hogy 
a hálózati telepítés fogalma nem feltételezi 
speciális szolgáltatások üzemeltetését, hiszen 
egy hálózati megosztáson tárolt (WIM állo- 
mánnyal és egy rugalmasan kezelhető USB-s 
merevlemezzel ki is válthatjuk a körülményes 
bootCD vagy -DVD lemezeket. Ha tovább 


szeretnénk egyszerűsíteni telepítőműhelyün- 








ket, a következő lépés, hogy magát a telepítő- 
klienst (WinPE) is hálózaton keresztül juttat 
juk el a telepítendő számítógépre. Erre a PXE 
(Preinstallation  Executable Environment) 
szolgáltatás képes, mely része a Windows 
Deployment Services-nek (WDS). Működé- 
sének feltétele IP-alhálózatonként egy Win- 
dows Server 2003 (bármelyik verzió), PXE- 
képes hálózati kártyák a telepítendő gépeken, 
illetve a WDS boot store-ban tárolt WinPE- 
kliens megfelelő felkészítése (például hálóza- 
tikártya-driver, megfelelő alkalmazások). 
Miután a kiválasztott kliens RAMdiskként 
letöltődött a célgépre, funkciójától függően 
kimásolhatunk WIM lemezképeket a WDS 
image storejából, készíthetünk lemezképet a 
célgépről. Sőt, ha további alkalmazásokat is 
elhelyezünk a WinPE RAMdisken, akár ví- 
rust is ellenőrizhetünk, vagy éppen terminál 
kliens segítségével vékonykliensként használ 


hatjuk ezt a számítógépet. 


Hálózat: az erő és a multicast 
velünk van 
Az előzőekben felsorolt eszközök közül a 
WDS ad lehetőséget arra, hogy célszámí- 
tógépünket a legkényelmesebben, illetve a 
legkevesebb hibalehetőséggel telepítsük. Az 
utóbbit arra értem, hogy esetleg a témában 
annyira nem járatos személyre is rábízhatjuk 
a telepítést, mivel a beállításokat központi 
lag adjuk meg, az opciók közül csak válasz- 
tani kellő 

A WDS-szolgáltatásnak otthont adó számí- 
tógépnek tartományi tagnak kell lennie. Az 
igazi rugalmasságot adó PXE bootlehetőség 
használatához a WDS-szerver IP-hálózatán 
szükséges dinamikus IP-címosztás (DHCP). 
EZÜtÁKKÉ csak azt vagy sazokat as WinBE 
klienseket kell létrehoznunk, amelyek kö- 
zül a célgépen a PXE-kliens letöltése előtt 
választhat az operátor. Több boot image-t is 
felvehetünk, de a célgép választóképernyőjén 
maximum 15 különböző boot image-t jele- 
níthetünk meg egyszerre. Alapvetően kétféle 
boot image-t tudunk itt használni, mégpedig 
Deploy (telepítő) és Capture (lemezkép-készí- 
tő) RAMdisket. A discovery image lényege, 
hogy nem PXE módon indítjuk el a célgépet, 
hanem valamilyen lemezes médiáról, de a fel 
adata ugyanaz lesz, mint az előbb említett két 
alaptevékenység. 

Előzetesen el kell döntenünk, milyen ar- 


chitektúrán (x86, x64) szeretnénk futtatni 


[A 
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windows Boot Manager (Server IP: 192.168.010.009) 


choose an operating system to start: 


(Use the arrow keys to highlight your choice, then press ENTER.) 


capturel 


To specify an advanced option for this choice, press F8. 


Maximum 15 , indítólemez"-ből válogathatunk hálózaton keresztül 





() operációs rendszert fel 
tölthetjük a WDS tárolóte- 
rületére. Megjegyzem, a mű- 
velet ugyanaz, mint ha kéz- 
zel (Imagex) elkészítenénk a 
MNWIM állományt, majd im- 
portálnánk közvetlenül a te- 


lepíthető lemezképek közé. 


.WIM-importálás 
Miután beállítottuk, hogy a 
PXE segítségével telepíten- 





List of Available Images 


C§ Windows Deployment Services - Add Image Wizard j 


dő gépeink hozzáférhetnek 
a WDS szolgáltatásaihoz, és 





képesek a telepítőkliens le- 





Windows Vista HOMEPREMIUM x86 
Windows Vista ULTIMATE x86 
Windows Vista HOMEBASICN  x86 
Windows Vista BUSINESSN x86 
Windows Vista STARTER x86 





IV Use default name and description for each of the selected image 


The following images are available in the file. Select the images you want to add. 


töltésére, jöhet a jól letesztelt 


etalon-operációsrendszereink 


Name sa —] Arehítecture [ Desciiption 3 hi MS T 
TESTET 8 Windows Vista BUSINESS importálása a WDS tárolóte- 
Windows Vista HOMEBASIC  x86 Windows Vista HOMEBASIC rületére (WDS image store). 


Windows Vista HOMEPREMIUI 
Windows Vista ULTIMATE 
Windows Vista HOMEBASICN 
Windows Vista BUSINESSN 
Windows Vista STARTER 


A WDS szabványos .WIM 
állományt vár bemenetként, 
amelyben tárolt lemezképek- 
ből még utólag válogatha- 
2] tunk is jelölőnégyzetek segít 

ségével. ImageGroup-onként 


fog keletkezni egy tárolóegy- 





z Back 





tartalmából 


RAMdiskünket, majd a megfelelő BOOT. 
WIM állományt kell importálnunk, amelyet 
érdemes egy Windows Server 2008 telepítő- 
lemezről beszerezni (Sources mappa). Ezen 
a WinPE-példányon fog futni az a kliens- 
program, amely hitelesítés után képes lesz 
a WDS-szerveren tárolt lemezképek közül 
a célgépre kimásolni a szükséges etalonpél 
dányt. A capture image készítése boot image- 
ből lehetséges, a különbség annyi, hogy letöl 


tődés után az adott számítógépen sysprepelt 


e BT A Véindows telepítése 
delőlje hi a telepítendő operációs rendszert. 


. Operációs rendszer 


Windows Vista UI TIMATI 
Vindows Vista BUSINESS 


Leírás: 
Windows Vista ULTIMATE 


(.Kovébb ] [/ 





" Információgyűjtés 


2 A Windows telepítése 


A telepítés ismerős. . . 


R 


WDS store importja esetén tovább válogathatunk a .WIM állomány 








SZER ség Falholuhasonlóam "assis 
(Single Instance Store) lehe- 
tőségeit kihasználva, helyta- 
karékosan fognak tárolód- 
hi az importált állományok. 
Figyelem: az alapértelmezett CűüXRemotelns- 
tall könyvtár tartalmát közvetlenül csak a 
WDS szolgáltatáson keresztül kezeljük! Ha 


módosítani szeretnénk valamelyik [mage-ün- 





Server Manager (WDSTRANSPORT) 
ZP Roles 
F a Active Directory Domain Services 
F 2 DHCP Server 
3] a DNS Server 
- MI Windows Deployment Services 
BI 3A Servers 
7 Tb wdstransport. wds.local 
Ig (A Install Images 
a ImageGroupi 
(E) Boot Images 
A] [2 Legacy Images 
B (43 Pending Devices 
A] (Ai Multicast Transmissions 














A Windows Vista ULTIMATE 
ET Windows Vista BUSINESS 










































































égi Features 
Hu Diagnostics 
HÜ; Configuration 
ÉS storage on the server. 


Unattend Hle Path: 


the new file. 





























o select Unattend File E 


Enter the unattend file path. This file will be uploaded as Imagellnattend xmi 


fc ARemotelnstalluwdsClient UInattendvunattend xmi 


If unattend file for the selected image already exists, ít will be overwritten with 


OK Cancel 


E ze 


ket, az Image-en kattintva exportáljuk .(WIM 
állományba, ekkor ImageX-szel már kezelhe- 
tő, majd módosítás után a Replacesszel kicse- 
rélhetjük az eredeti lemezképet. Ekkor ismét 


csak a módosítások tárolódnak. 


Mi újság az egyediesítéssel? 

Aki telepített már Vistát, annak a PXE-boot 
után már nem lesz ismeretlen a felület, amely 
első lépésében választanunk kell, melyik tá- 
rolt operációs rendszert szeretnénk a célgépre 
helyezni. Ha az eredeti telepítőlemezről indí- 
tanánk ebben a fázisban a telepítést, akkor is 
van lehetőségünk a válaszállományt mond- 
juk egy pendrive segítségével megadni az ope- 
rációs rendszernek (vigyázat: XP-nél ez kissé 
körülményesebb). A WDS-nél viszont köthet 
jük az adott lemezképhez a válaszállományt, 
így kényelmesen, központilag választhatunk 
a rendelkezésre álló válaszfájlok közül (tehát 
nem kell a kliensgépnél sorban állni a cserél 


hető médiával, bár a lehetőség adott erre is). 


Nulticast 

Ha WDS-szerverünk Windows Server 2008- 
on fut, és a terjesztendő lemezképünk is ilyen 
verziójú, lehetőségünk van a telepítőcsoma- 
gokat multicast hálózati forgalom használatá- 
val célba juttatni. Finoman szólva is nagyobb 
hatásfokkal kerülnek ki ezek a 45 gigabájt 
méretű csomagok a célgépekhez. Aki eset 
leg nem tudná, mi is a multicast, annak egy 
egyszerű példával hadd tegyem szemléletessé. 
Mekkora sávszélességet visz el egy darab ope- 


rációs rendszer telepítése hálózaton keresz- 


General I Version ] Security ] 
SY [Windows Vista ULTIMATE 


install Image 
Online 














Image type: 
State: 











Architecture: x86 
Description: [Windows Vista ULTIMATE 





2 ImageGroup 1 


install-(2).wim 
8176 MB (8573967175 bytes) 





2008. január 21. 3:48:16 
2008. június 23. 13:04:38 





acpiapic 





[7 Allow image to install in unattended mode 


Etalonpéldányonként központilag választhatjuk az egyedivé tételt 
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Várakozás a kiszolgálóra... A Windows telepítése... 


Jelenleg ennyi információra volt szükség. A telepítés során a számítógép többször újra fog indulni. 


A telepítés automatikusan folytatódik, amikor a kiszolgáló kezdeményezi a IRS 
munkamenetet, / Fájlok másolása 

Fájlok kibontása (196) . 

Összetevők telepítése 

Frissítések telepítése 


A telepítés befejezése 


 EZEZEEEESSZ  ] EI — ze] 


n Információgyűjtés 3; Fellegi a x$ Információgyűjtés B, Evt ele edd ge ési g 


Ha van multicast munkamenet definiálva a választott lemezképhez, ennél 


a képernyőnél várják be egymást a számítógépek 


tül? Legyen X. Mekkora sávszélességet visz 
el húsz darab oprendszer egyidejű telepítése 
multicast segítségével? 20X? Nem! Csupán 
X! Teljesen mindegy, hány gépet telepítünk 
egyszerre, a telepítőcsomag egy példányban 
megy át a hálózaton. Így szoktunk mi pénte- 
kenként komplett tantermeket újratelepíteni 
(egyszerre akár négyetötöt) friss operációs 
rendszerrel akár egy órán belül... 

A multicast beállítása igen egyszerű: a tele- 
pítendő lemezkép kiválasztása után időpont 
hoz vagy kliensszámhoz ütemezve kell mun- 
kamenetet létrehozni, majd amikor minden 
feltétel teljesül, a forgalom nem unicast, ha- 
nem multicast formában indul el. Mivel a 
válaszállomány lemezképhez köthető, az ilyen 
formájú telepítés esetén az egyediesítést kézzel 
vagy egyedi állománnyal (gépenként külön 
pendrive, ahol az egyedi beállításokat tároló 


unattend.xml foglal helyet) kell megoldani. 


Transport server 

Végül - csak hogy teljes legyen a paletta 
- felhívnám a figyelmet a Iransport server 
lehetőségeire. Ennek a WDS-től függetle- 
nül telepíthető szolgáltatásnak a feladata az 
állományok másolása multicast segítségével. 
Ebben az esetben nem az operációs rendszer 
telepítéséről van szó, hanem élő operációs 
rendszerek csoportjára utólag egy menetben 
ki lehet másolni így bármit. Hogy milyen ál 
lományokat érdemes kimásolni működő ope- 
rációs rendszerbe? Természetesen nagymére- 
tű állományokat, például virtuális gépeket 
vagy komplett műsoros DVD-állományokat, 


esetleg operációs rendszereket. Belátható, 


MÁJUS-JÚNIUS 





Maga a telepítés viszont teljesen ugyanúgy folyik a továbbiakban, mintha 


a klasszikus módon, telepítőmédiáról tennénk 





vV/US5 Store 








. Urnicast forcdialam ; 






Transport-kllansak 
multicast 





A Transport Server működése 


hogy viszonylag kicsi az alkalmazási terület, 
illetve nem is teljesen a tömeges telepítés 
témaköre, ezért a részletesebb beállítási lehe- 
tőségeket más alkalommal tárgyaljuk - ergo, 
most csak röviden emlékezünk meg erről. 
Ez a meglehetősen robusztus szolgáltatás a 
WDS erőforrásait képes használni (Image 
store), és a saját IP-alhálózatán terjeszteni azt. 
Konfigurálni a WDSUTIL-al lehet (amellyel 
egyébként a WDS is konfigurálható). A cél 
gépeken bármilyen operációs rendszer futhat 
(Windows XP, WinPE is), mivel parancssor- 
ból kell kezdeményezni minden adatátvitelt 


(WDSMCAST, az AIK része...). 


Remélem, a cikk végére érve jó néhány 
felhőt 
amely a hálózatos telepítést övezi. 

A rengeteg rövidítés (WIM, WDS, AIK, 


PXE stb.) elsőre valószínűleg zavaró lehet, 


misztikus sikerült  szétoszlatnom, 


viszont ha az ember pár órát eltölt a WDS- 

sel, hamarosan fejből fogja fújni ezeket. A 

telepítőlemezek számának csökkenésével pe- 

dig "hozzájárulunk "a Föld" faállományának 
védelméhez. 

Réczi Gábor 

MCSE, MCT, SBS MVP 

(reczi. gaborDnetacademia. net) 

NetAcademia 
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ACTIVE DIRECTORY: 


INFORMÁCIÓK 





LEKÉRDEZÉSE 





Ebben a cikkben a PowerShell erejét szeretném bemutatni 


az Active Directoryval kapcsolatos üzemeltetési feladatok során. 


zoknak, akik már készítettek VBScripttel ADSLszkripteket, 

lesz sok ismerős elem, számukra a PowerShellmegvalósítás egy- 

szerűsége lesz az érdekes. Akik korábban nem éltek a VBscript 
lehetőségével, mert a bonyolult szintaxis elvette a kedvüket, azok 
most a PowerShell egyszerűsége által kaphatnak kedvet a parancsso- 
ros környezet használatához. 

A PowerShell segítségével az Active Directoryval kapcsolatos fel 
ügyeleti tevékenységek is hatékonyan automatizálhatók. Miután a 
PowerShell alatt a .NET keretrendszer található, így fontos ismerni az 
ezzel kapcsolatos fontosabb osztályokat. 

Mivel az Active Directory-hibák 110 százaléka valamilyen DNS-ht- 
bára vezethető vissza, így elsőként ellenőrizzük a névfeloldást. Az ezzel 
kapcsolatos .NETosztály a System.Net .Dns, amelynek GetkHostEntry statikus 
metódusával tudjuk ellenőrizni például a tartományvezérlőnk nevé- 
nek feloldását: 


PS C: WserstAdministratorz [System.Net.Dns] : : GetHostEntry( "adds . igjb 
.w08") 


AddressList 


tgz et 42 


Aliases 


HostName 


adds . igjb.w08 () 


Ha ez helyes eredményt ad, akkor folytathatjuk az AD felderíté- 
sét, ellenőrzését az erdő legfontosabb objektumaival. Erre a célra a 
System.DirectoryServices.ActiveDirectory.Forest osztály alkalmas, annak is a 


GetCurrentForest statikus metódusa: 


PS C: WserstAdministratorz [System.DirectoryServices.ActiveDirectory. 
Forest] : :getcurrentforest () 


Name : igjb.w08 

Sites : (Default-First-Site-Namel 
Domains : (igjb.w08) 
GlobalCatalogs : (adds.igjb.w0O8) 
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(DC-ForestDnsZones ,DC-igjb,DC-w08, DC-DomainDnsZone 
s, DC-igjb,DC-w08] 


ApplicationPartitions : 


ForestMode : Windows2008Forest 

RootDomain : igjb.w08 

Schema : CN-Schema , CN-Configuration, DC-igjb, DC-w08 
SchemaRol e0wner : adds .igjb.w08 

Nami ngRol e0wner : adds .igjb.w08 


Láthatjuk, hogy ez a metódus a legfontosabb adatokat megadja az 
erdőről: a root tartomány és a többi tartomány nevét, a globális kata- 
lógusok listáját, az erdő működési szintjét és az erdő szintű egyedi sze- 
repeket hordozó tartományvezérlők neveit. 

Hasonló módon megvizsgálhatjuk az aktuális tartomány adatait is 
a System.DirectoryServices . ActiveDirectory. Domain osztály getcurrentdomain stati- 


kus metódusának segítségével: 


PS C:WserstAdministratorz [System.DirectoryServices .ActiveDirectory 
.Domain] : : getcurrentdomain() 


Forest : igjb.w08 
DomainControllers : (adds.igjb.w08) 
Children silt 

DomainMode : Windows2ZOO8gDomain 
Parent ; 

PdcRoleOwner : adds.igjb.w08 
RidRole0wner : adds. igjb.w08 
InfrastructureRole0wner : adds.igjb.w08 
Name : igjb.w08 


Itt a legfontosabb pluszinformációnak a tartományi szintű egyedi 
szerepeket hordozó tartományvezérlők nevei számítanak. 

Nem mellékes, hogy milyen AD site- (telephely) beállításokkal 
dolgozunk, hiszen ez befolyásolja az ügyfélgépek tartományvezérlő 
választását és a címtárreplikációt. A telephelyiinformációk kiolva- 
sására a System.DirectoryServices.ActiveDirectory.ActiveDirectorySite osztály 


GetComputerSite statikus metódusa használható: 
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PS C:e [ISystem.DirectoryServices.ActiveDirectory.ActiveDirectorySitel : : 
GetComputerSite() 


Name : Default-First-Site-Name 
Domains (igjb.w08] 

Subnets (192.168.112.0/24) 
Servers : (w2k8.igjb.w08) 
AdjacentSites ST 

SiteLinks (DEFAULTIPSITELINK) 
InterSiteTopol ogyGenerator : w2k8. igjb.w083 

Options : None 

Location : Budapest 


BridgeheadServers 3 1) 

PreferredSmtpBridgeheadServers : () 

PreferredRpcBridgeheadServers  : ()] 

IntraSiteReplicationSchedule — : System.DirectoryServices.ActiveDirectory. 
ActiveDirectorySchedule 


Ezzel a néhány kifejezéssel tehát elég jól át lehet tekinteni, hogy mi- 
lyen az ADinfrastruktúránk, fájlba történő átirányítással akár az AD- 


infrastruktúránk dokumentálásához is segítséget kapunk. 


Csatlakozás az Active Directoryhoz 

Az előzőekben a .NET keretrendszer osztályainak statikus metódu- 
saival dolgoztam, amelyek segítségével általános információkat le- 
hetett kinyerni az Active Directory környezetről. Ha konkrét, adott 
tartományra vagy címtárelemre vonatkozó információkhoz akarunk 
hozzájutni, akkor csatlakozni kell az adott címtárobjektumhoz. A 
címtár kezelésében fontos szerepe van a gyorsítótárnak, egy ilyen 
csatlakoztatás előkészíti az adott címtárobjektum memóriabeli rep- 
rezentációját. Ha ezek után változtatunk a beolvasott objektum va- 
lamely tulajdonságán, akkor ez csak a memóriában hajtódik végre, 
külön metódussal kell ezt a változást a címtárba visszaírni, amint ezt 
látni fogjuk. 


Elsőként azonban nézzük meg a legegyszerűbb csatlakoztatást: 


PS C:P $domain - [ADSI] "" 


Az [ADSI] típusjelölővel hivatkozunk a címtáras elérésre, és ha egy 
üres sztringet adunk meg a ,konstruktor" paramétereként, akkor az 
adott tartomány tartományobjektumához csatlakozunk. Ez a típus- 
jelölő a System.DirectoryServices .DirectoryEntry .NET osztály rövidített ne- 
ve. Ezt akár ki is írhatjuk, és ekkor további paramétereket is meg- 


adhatunk, ha szükséges: 


PS C:B $domain - new-object DirectoryServices .DirectoryEntry(,", "igjb) 
Administrator", ,Password1") 


A fenti példában megadtam azt, hogy kinek a nevében csatlako- 
zom, és mi ennek a fióknak a jelszava. 


Olvassuk ki, hogy mi került a $domain változónkba: 
PS C:B $domain 
distinguishedName 


(DCsigjb,DC-w08) 


Ez még nem túl sok, ennek a részletes tulajdonságait később mu- 
tatom be. Most nézzük, hogyan tudunk egy nevesített objektumhoz, 


mondjuk, egy felhasználói fiókhoz csatlakozni: 
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[mlEl] xXx 


PS C:PB $user - [ADSI] ,LDAP://cn-János Vegetári,ou-Demó, dczigjb, dc-w08" 
PS C:P $user 


distinguishedName 


(CN-János Vegetári,0U-Demó , DC-igjb,DC-w08) 





Az [ADSIT utáni sztringben csupa nagybetűs az LDAP, és normál perjelek vannak utána. 
Ha nem csupa nagybetűs az LDAP, vagy fordított perjelet használunk, akkor nem rögtön 
kapunk hibajelzést, hanem csak akkor, amikor először használjuk az objektumot. 





AD-objektumok létrehozása 
AD-objektumokat létrehozni a korábban már VBScriptből megszo- 
kott ADSLszintaxishoz nagyon hasonló módon lehet. Először egy 
AD-konténerre kell csatlakozni, ahova létre szeretnénk hozni az új 
objektumot. Ez a csatlakozás a már látott módon megy, ezzel, ugye, 
,átemeljük" a PowerShellbe az adott konténert mint objektumot. Az 
így ,átemelt" AD-objektum Create metódusával lehet létrehozni az új 
AD-elemet. A Create paramétereként meg kell adni a létrehozandó ob- 
jektum típusát és a , relative distinguished namef-et, azaz az adott kon- 
téneren belüli megkülönböztető nevét. 

Az alábbi példában magán a tartományvezérlőn (localhost), közvet 
lenül a tartományobjektum alá hozok létre egy szervezeti egységet (or- 


ganizational unit): 


PS C:P $konténer - [adsi] ,LDAP://localhost:389/dczigjb, dc-w08" 

PS C:B $adobj - $konténer.Create(,OrganizationalUnit", ,0U-Emberek") 
PS C:P $adobj.Put(,Description", ,Normál felhasználók") 

PS C: $adoObj.Setlnfo() 


Ebben, ugye, az az újdonság, hogy az LDAP kifejezésbe beillesztet 
tem a tartományvezérlő nevét és a portszámot is, ahol a címtárszolgál- 
tatás elérhető. A szemléltetés kedvéért még a , Description" attribútu- 
mát is kitöltöttem. Vigyázat, amit idáig tettem, azt mind a memóriá- 
ban végeztem el, ahhoz, hogy mindez ténylegesen bekerüljön a címtár 


adatbázisba, meg kell hívni a SetInfo metódust! 


AD-objektumok tulajdonságainak kiolvasása, módosítása 
Ha PowerShell, akkor objektumok. Az előzőekhez hasonlóan csatla- 
kozzunk a most létrehozott szervezetiegység-objektumhoz, és nézzük 


meg a tagjellemzőit a get-member cmdlet segítségével: 


PS C:B $adou - [LADSI] ,LDAP://0U-Emberek,DC-igjb,DC-wOg" 
PS C:P $adou [ get-member 


TypeName: System.DirectoryServices .DirectoryEntry 


Name MemberType Definition 

description Property System.DirectoryServices .PropertyValuec . . . 
distinguishedName Property  System.DirectoryServices .PropertyValuecC . . . 
dSCorePropagationData Property — System.DirectoryServices.PropertyValuec.. . 
instancelype Property System.DirectoryServices .PropertyValuecC.. . 
name Property System.DirectoryServices.PropertyValuec. . . 
niSecurityDescriptor Property — System.DirectoryServices.PropertyValuec . . . 
objectCategory Property System.DirectoryServices .PropertyValuec . . . 
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objectClass Property  System.DirectoryServices.PropertyValuecC . . . 
objectGUID Property  System.DirectoryServices.PropertyValuecC . . . 
0Uu Property System.DirectoryServices.PropertyValuecC . . . 
usSNChanged Property  System.DirectoryServices.PropertyValuec. . . 
uSNCreated Property  System.DirectoryServices.PropertyValuecC. . . 
whenChanged Property  System.DirectoryServices.PropertyValuecC. . . 
whenCreated Property  System.DirectoryServices.PropertyValuecC . . . 


Hát elég furcsa, amit kaptunk. Látjuk a szervezeti egységünk tu- 
lajdonságait - de hol vannak a metódusok? Hol a Create? Sajnos, a 
PowerShell 1.0-ba még nincsen 100 százalékban adaptálva a System. 
DirectoryServices osztály. Ennek több oka is van. Az egyik, hogy való- 
jában itt nem színtiszta NET-osztályról van szó, hanem COM-objek- 
tum is meghúzódik a felszín alatt, és annak metódusait nem olyan 
egyszerű átemelni. Gondoljunk csak arra, hogy egy ilyen DirectoryEntry 
típusú objektum lehet felhasználói fiók, számítógépfiók, telephely, 
csoport stb., ezeknek mind más és más metódusuk van, ezeknek az 
adaptálása a PowerShelkkörnyezetbe nem olyan egyszerű. Ebből szár- 
mazik a második ok is, hogy a fejlesztők az 1.0 megjelenését nem akar- 
ták ezzel késleltetni, várhatóan a 2.0 verzió már precízebb AD-támo- 
gatást fog nyújtani. 

Szerencsére van egy kis menekvési ösvényünk, azaz kikapcsolhat 
juk a PowerShell adaptációs rétegét, és megnézhetjük a , színtiszta" 


.NET objektumot is a psbase nézeten keresztül: 


PS C:PB $adou.psbase ] get-member 


TypeName: System.Management .Automation. PSMemberSet 


Name MemberType Definition 

MoveTo Method System.Void MoveTo(DirectoryEntry n... 
RefreshCache Method System.Void RefreshCache(), System. ... 
remove Disposed Method System.Void remove Disposed(EventhHa. . . 
Rename Method System. Void Rename(String newName) 
ToString Method System.String ToString() 
Authenticationlype Property  System.DirectoryServices.Authentica. .. 
Children Property System.DirectoryServices.DirectoryE. . . 
Container Property System.ComponentModel . IContainer Co... 
Guid Property  System.Guid Guid íget;) 

Name Property  System.String Name íget;] 

NativeGuid Property  System.String NativeGuid íget;) 
NativeObject Property  System.Object NativeObject (get;) 
ObjectSecurity Property System.DirectoryServices.ActiveDire... 
Options Property System.DirectoryServices.DirectoryE. . . 
Parent Property  System.DirectoryServices.DirectoryE... 
Password Property  System.String Password íset;) 

Path Property  System.String Path íget;set;) 
Properties Property  System.DirectoryServices . PropertyCo. . . 


A fenti, kicsit megvágott, de még így is hosszú listából látszik, hogy 
az objektumot valójában lehet például mozgatni, átnevezni, és néhány 
újabb tulajdonság is feltárul a szemünk előtt. De például még mindig 
nem látjuk a SetInfo és a Create metódust, mert ezek az ADSI COM in- 
terfészéből jönnek, és a NET nem kérdezi le, így nem is mutatja meg, 
viszont meghívni, használni ennek ellenére lehet őket. 


Vagy nézzük a következőket: 


SEC de [AOSTÁTASA 
DSNOSAE Ea] 


2 2 


ma! E pá 


distinguishedName 


(DCsigjb, DC-w08) 


A fenti módon például nagyon egyszerűen lehet az aktuális tarto- 
mányunkhoz csatlakozni. Próbáljuk meg ennek megnézni a , rejtett" 


children tulajdonságát: 


PS C:W $adou - [ADSI] ,LDAP://OU-Demó, DC-igjb,DC-w08" 
PS C:P $adou.psbase.Children 


distinguishedName 

CN-Csilla Fájdalom, 0U-Demó , DC-igjb,DC-wO8) 
CN-Csoport , 0U-Demó , DC-igjb, DC-w08] 
CN-group1, 0U-Demó , DC-igjb,DC-w08] 

CN-János Vegetári,0U-Demó DC-igjb,DC-wO8g) 
CN-Márton Beléd, 0U-Demó ,DC-igjb,DC-w08] 


— e 


Hiszen ez megadta az adott konténerobjektumban található al 
objektumokat! Mindebből az következik, hogy nem érdemes még 
kidobni korábbi ADSLismereteinket, illetve ismernünk kell az AD- 
objektumok tulajdonságainak neveit, hogy ezeket a tulajdonságokat 
lekérdezhessük és módosíthassuk. Nézzünk erre egy példát egy fel 
használói fiókkal kapcsolatban. Van egy már létező felhasználóm, 
annak szeretném kiolvasni és beállítani a teletonszám-tulajdonságát. 
Ehhez kell nekünk az, hogy tudjuk: mi is a belső elnevezése az AD- 
ben a telefonszám-tulajdonságnak. Ennek felderítésére nézzünk egy 


PowerShellmódszert: 


PS C:P $user - [ADSI] ,LDAP://cn-János Vegetári,0U-Demó,DC-igjb,DC-wO8" 
PS C:P $user.psbase.properties 


PropertyName Value Capacity Count 
objectClass ítop, person, o... 4 4 
cn János Vegetári 4 1 
sn Vegetári 4 1 
telephoneNumber 2008 4 1 
givenName János 4 1 
distinguishedName CN-János Vegetá... 4 1 


A fenti listában látjuk, hogy a telefonszám-attribútum neve - meg- 
lepő módon - telephoneNunber . 
Nézzük meg, hogyan lehet ezt a telefonszámot kiolvasni, majd átír- 


ni. Az első megoldás a , PowerShellbstílusú ": 


PS C:PB $user.telephoneNumber 

1234 

PS C:WB $user.telephoneNumber-2008 
PS C:P $user.setinfo() 

PS C:PB $user.telephoneNumber 

2008 


Jóllehet a Get-Member-rel nem lehetett kiolvasni, hogy a $user-nek van 
telephoneNumber tulajdonsága, mégis lehet használni. 


A második megoldás a hagyományos, ADSLsstílus: 


PS C:P $u.Get(,telephoneNumber") 

it 

PS C: $u.Put(,telephoneNumber" , 9876) 
PS C:P $u.Setlnfo() 
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PS C:PB $u.Get (, telephoneNumber") 
98/6 


A Get metódussal tudjuk az adott tulajdonságot kiolvasni, a Put-tal 


átírni. Egyik esetben sem szabad megfeledkezni a Setlnforól, ami az 


objektum memóriabeli reprezentációját írja be ténylegesen az AD-ba. 


Megjegyzés 


Sajnos nem minden attribútum kezelhető a PowerShell-módszerrel. Ilyen például a 


Company attribútum: 

PS C:W $u.company 

PS C:B $u.get(, company") 
Cég 








Az első esetben nem kaptam semmilyen választ az attribútum kiol 
vasására, de get-tel mégis működött. 

Mi van akkor, ha kiolvastuk egy felhasználó adatait egy változóba, 
majd ezután valaki egy másik gépről vagy egy másik alkalmazással 
módosítja a felhasználónk valamely attribútumát. Ilyenkor a getinfo 


metódussal lehet frissíttetni az adatokat a memóriában: 


PS C:B $u.get (, company") 

Egyik 

PS C:B $u.getinfo() 

PS C:PB $u.get(, company") 

Másik 

A fenti példában az első kiolvasás után a ADUC eszközzel átírtam 
a felhasználó Company attribútumát, és a getinfo-val ezt frissítettem a 


memóriában, így az új érték már a PowerShellből is látszik. 


Munka többértékű (multivalued) attribútumokkal 


Az Active Directory egyik jellegzetes attribútuma a , multivalued pro- 
perty". Ez olyan tulajdonság, ahova az értékek listáját, tömbjét tehet 
jük. Legtipikusabb ilyen attribútum az Exchange Server bevezetése 
után a felhasználók e-mail-címeit tartalmazó ProxyAddresses vagy a cso- 
portok Member attribútuma, de ez utóbbit külön kezeljük speciális me- 
tódusokkal. Maradnak mondjuk az other... kezdetű különböző telefon- 
számok tárolására szolgáló attribútumok, mint például az otherMobile 
vagy az otherTelephone. 

Ezeket ki lehet olvasni az eddig megismert módszerekkel is, de néz- 
zük, hogy milyen problémákkal szembesülhetünk. Ha a get metódust 
használom, és csak egy értéket tárol a , multivalued propery", akkor 


nem egyelemű tömböt kapok, hanem sima skaláris értéket: 


PS C:E $user.get(,otherMobile") 
othermobi 11234 
PS C:PB $user.get(,otherMobile") .gettype() 


IsPublic IsSerial Name Baselype 


True True String System. Object 


Ezzel szemben, ha több értéket tárolunk, akkor már tömböt kapunk: 


PS C:PE $user.get(,otherMobile") 
othermobi 12345 
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othermobi 11234 
PS C:P $user.get(,otherMobile") .gettype() 


IsPublic IsSerial Name Baselype 


True True Object[] System.Array 


Ez nem biztos, hogy jó nekünk, mert így a szkriptünket kétfajta 
esetre kell felkészítenünk: külön arra az esetre, ha csak egy értéket tá- 
rolunk, és külön arra az esetre is, ha többet. Ez bonyolítja a program- 
jainkat. Ha konzisztensen, mindig tömbként akarjuk kezelni az ilyen 


multivalued propertyket, akkor vagy használjuk a PowerShellstílust: 


PS C:B $user.otherMobile 
othermobi 11234 
PS C:P $user.otherMobile.gettype() 


IsPublic IsSerial Name Baselype 


True False — PropertyValueCollection System.Collec... 


Vagy használjuk a GetEx metódust: 


PS C:B $user.getex(,otherMobile") 
othermobi 11234 
PS C:B $user.getex(,otherMobile") .gettype() 


IsPublic IsSerial Name Baselype 


True True Object[] System.Array 


Nem tökéletesen egyforma a két kimenet típusa, de mindkettő 
tömb (collection) típusú. 

Az ilyen multivalued propertyk írása sem egyértelmű, hiszen több 
lehetőségem is van: 
a a meglevő értékekhez akarok egy újabbat hozzáfűzni, 
a a meglevő értékek helyett akarok egy vagy több újat betölteni. 

Ezeket a lehetőségeket én magam is tudom programozni a szkrip- 
temben. Ha az első változatra van szükségem, akkor előbb kiolvasom 
az attribútum aktuális tartalmát egy változóba, hozzárakom az új érté- 
ket, és így rakom vissza a put-tal vagy egyszerű értékadással. Ha pedig 
a második változatra van szükségem, akkor egyszerűen felülírom az 
attribútumot az új értékkel. 

Sokkal elegánsabb, ha ezt már maga az objektum tudná egy , oko- 


sabb" metódussal. Ilyen létezik, mégpedig a PutEx: 


PS C:B $user.getex(,otherMobile") 

othermobi 11234 

PS C:B $user.putex(3, "otherMobile" , e ( ,othermobi IPutEx2") ) ; $user. setinfo() 
PS C:B $user.getex(,otherMobile") 

othermobi I PutEx2 

othermobi 11234 

PS C:B $user.putex(2, "otherMobile", e ( ,othermobi IPutEx3") ) ; $user. setinfo() 
PS C:B $user.getex(,otherMobile") 

othermobi I PutEx3 


A fenti példában a kiinduló állapotban egy mobilszámunk van. 
Ezután hozzáfűzök egy újabbat a putex használatával, a hozzáfűzést az el- 
ső paraméterként szereplő 3-as jelzi. Fontos, hogy a hozzáfűzendő érté- 
ket tömbként kell kezelni, ezért van ott a kukaczzárójelpár! Ezután egy 
újabb putex-ret hívok meg, immár 2-es paraméterrel, ez a felülírás műve- 


lete, hatására már csak ez a legújabb mobilszám lesz az attribútumban. 
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Használhatok még 1-es paramétert is, ez ekvivalens az attribútum 
értékeinek törlésével, vagy használhatok 4-es paramétert, ez egy ele- 


met töröl az értékek közül: 


PS C:B $user.putex(3, "otherMobi le", 0(,Append") ) ; $user. setinfo() 
PS C:PB $user.getex(,otherMobile") 

Append 

othermobi I PutEx3 

PS C:B $user.putex(4, "otherMobi le", 0(,Append") ) ; $user. setinfo() 
PS C:E $user.getex(,otherMobile") 

othermobi I PutEx3 


A fenti példában elsőként hozzáfűzök egy értéket, majd ugyanezt 


eltávolítom. 


Speciális tulajdonságok kezelése 
Van néhány olyan attribútum, amelyek az eddig megismert módsze- 


rek egyikével sem kezelhetők: 


PS C:E $user.AccountDisabled 

PS C:P $user.get(,AccountDisabled") 

Exception calling ,get" with ,1" argument(s): ,The directory property canno 
t be found in the cache." 

At line:1 char:10 

t $user.get( cccc ,AccountDisabled") 


A PowerShellszintaxis meg se nyikkan, a get meg még hibát is jelez. 
Ilyen esetekben használhatjuk a psbase nézeten keresztül az InvokeGet és 


InvokeSet metódusokat: 


PS C:PB $user.psbase. invokeget ( ,AccountDisabled") 

False 

PS C:PB $user.psbase. invokeset ( ,AccountDisabled" , "TRUE") 
PS C:B $user.Setlnfo() 


Jelszó megváltoztatása 

Speciális attribútum a jelszó, hiszen tudjuk, hogy valójában nem (fel 
tétlenül) tárolja a címtár a jelszavakat, hanem csak a belőlük képzett 
hasht. Így a jelszó kezelésekor nem egyszerűen egy attribútumot kell 
beállítani, hanem ezt a hasht kell képezni. Szerencsére erre a célra 


rendelkezésünkre áll két metódus, a SetPassword, illetve a ChangePassword: 


PS C:B $user.SetPassword("UjPass2") 
PS C:E $user.ChangePassword("UjPass2" , "MégújabbPass3") 


A SetPassword felel meg a Reset Password műveletnek. Ezt, ugye, csak 
megfelelő rendszergazdai jogosultságokkal tudjuk meghívni. A Change- 
Password a meglevő jelszó birtokában módosítja a jelszót, ehhez már 
nem kell külön rendszergazdai jogosultság. Mindkét metódus tényle- 


gesen be is írja az új jelszót a címtárba, tehát nincs szükség a SetInfora. 


Csoportok kezelése 
Az Active Directoryban csoportokat leginkább a rendszer üzemelte- 
tésének megkönnyítésére veszünk fel. Segítségükkel osztunk ki hoz- 
záférési jogokat, felhasználói jogokat, de még a csoportos házirendek 
érvényre jutását is szabályozhatjuk csoportokkal. Miután ilyen széles 
körű a felhasználásuk, fontos lehet a csoportok kezelésének automa- 
HIZAÁSA 

Erre is kiválóan alkalmas a PowerShell, nézzük meg a leggyakoribb 


műveleteket. 


ye 


e ze 


Csoportot létrehozni a már látott módszerrel lehet: 


PS C:P $target - [ADSI] ,LDAP://ou-Demó,DC-igjb,DC-wO8" 
PS C:P $group - $target.create(,group" , "CN-Csoport") 
PS C:P $group.setinfo() 


Ez alaphelyzetben globális biztonsági csoport. A későbbi, összetett 
példában majd bemutatom, hogyan lehet másfajta csoportokat is lét 
rehozni. 

Ezután kétféleképpen lehet tagokat adni a csoportokhoz. Az el 
ső módszer a hagyományos , ADSI-s módszer, ahol a csoport Add 
metódusát hívom meg, paramétereként a berakni akart felhasználó 
LDAP-os szintaxisú elérési útját kell megadni. Vagy ha már megra- 
gadtam a felhasználói fiókot, akkor vissza kell alakítani az LDAP-os 


elérési úttá, mint ahogy ebben a példában tettem: 


PS C:PB $user - [ADSI] ,LDAP://CN-János Vegetári,0U-Demó,DC-igjb,DC-w08" 
PS C:P $group. add(, LDAP: //$ ($user. distinguishedname) ") 
PS C:P $group.setinfo() 


Hasonlóan lehet tagot eltávolítani, csak az Add helyett a Remove metó- 
dust kell meghívni. 
A második módszer kicsit PowerShellbszerűbb, itt nem kell ide-oda 


alakítgatni, elég a felhasználó distinguishedname tulajdonságát használni: 


PS C:B $user - [ADSI] ,LDAP://CN-Csilla Fájdalom, 0U-Demó  DC-igjb,DC-wO8" 
PS C:P $group.member 4- $user.distinguishedname 
PS C:P $group.setinfo() 


Természetesen a két megoldás egyenértékű, csak stílusbeli különb- 
ség van közöttük. A második módszer hátránya talán, hogy egysze- 
rűen nem lehet csoporttagot eltávolítani, külön képezni kellene a 
nemkívánatos tag nélküli tömböt, és azt betölteni a csoport member 


tulajdonságába. 


Keresés az AD-ben 

Az igazán profi kereséshez a .NET keretrendszer egyik osztályát, a 
System.DirectoryServices .DirectorySearcher-t hívjuk segítségül, ennek egy 
objektuma lesz a keresőnk, és ennek különböző tulajdonságait beállít 
va adjuk meg a keresésünk mindenféle feltételét. Nézzünk egy nagyon 


egyszerű feladatot, egy konkrét felhasználói fiókra keressünk rá: 


[6] PS I:We$objRoot - [ADSI] ,LDAP://0U-IOJB,DC-kfki ,DC-corp" 

[7] PS I:S$objSearcher - New-Object System.DirectoryServices .DirectorySearc 
her 

[8] PS I:S$objSearcher.SearchRoot - $objRoot 

[9] PS I:W$objSearcher. Filter - ,(8(objectCategory-user) (displayName-So- 

ós Tibor))" 

[10] PS I:t$objSearcher.SearchScope - ,Subtree" 

[11] PS I:W$colResults - $objSearcher.FindAT1 () 

[12] PS I:Ee$colresults 


Path Properties 


LDAP: //CN-Soós Tibor,0U-Normat , 0U-. . . (homemdb, distinguishedname, count... 


Elsőként definiálom, hogy az AD adatbázis-elemek fastruktúrájá- 
ban hol is keresek majd ($objRoot). Majd elkészítem a keresőt ($objSear- 
cher), amelynek SearchRoot tulajdonságaként az előbb létrehozott keresé- 
si helyet adom meg. 


Majd definiálom az LDAPformátumú szűrőt, amely ebben az eset 
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ben a , Soós Tibor" nevű felhasználókat jelenti, és ezt betöltöm a kere- 
ső Filter tulajadonságaként. Végül meghatározom a keresés mélységét, 
ami itt Subtree, azaz mélységi, mert nem pont közvetlenül a kiinduló- 
pontként megadott helyen van a keresett objektum. Nincs más hát 
ra, ezek alapján ki kell listázni a feltételeknek megfelelő objektumo- 
kat a FindAl1 metódussal. 

A $colResult változóban tárolt eredmény nem közvetlenül DirectoryEntry 
típusú elemek tömbje, hanem egy hashtábla-szerűség, ahol a Path oszlop 
tartalmazza a megtalált objektum LDAP formátumú elérési útját, a 
Properties meg a kiolvasható tulajdonságait. Azaz ahhoz, hogy kiolvas- 


suk például az én nevemet és beosztásomat, egy kicsit trükközni kell: 


[25] PS I:"$($colResults[0] .properties .displayname) az én nevem, 
beosztásom $($colResults[0] .properties.title)" 
Soós Tibor az én nevem, beosztásom műszaki igazgató 


Megjegyzés 


PowerShell-ténykedésem során ez a második eset, amikor kis—nagybetű érzékenysé- 
get tapasztaltam! (Az első az LDAP: kifejezésnél volt, de ez félig-meddig betudható az 
ADSI-örökségnek.) A második ez: ha $colResults[0] .properties . displayName-et 
írok (nagy , N" az utolsó tagban), akkor nem kapok semmit. Ez azért is furcsa, mert 
eredetileg a címtárban nagy az , N". 





A következő példában egy függvényt hozok létre, amellyel felhasz- 
nálói fiókok tetszőleges attribútumát lehet tömegesen lecserélni vala- 
mi másra. A kód megfejtését az előzőek ismeretében az olvasóra bí- 
zom. Csak egy kis segítséget adok: a középrészen található If vizsgálat 
Else ágában azt érem el, hogy ha a kicserélendő attribútumérték üres, 
azaz azt szeretnénk, hogy a ki nem töltött attribútumokat töltsük ki, 
akkor az LDAPfilterben a !$Attr-" kifejezést kell szerepeltetni, ennek 
az a jelentése, hogy , az $Attr változó által jelzett attribútum nem egyen- 
ló akármi, azaz van értéke". 


function ModifyUserAttrib 
( 
param ( 
$domain - 
[System.DirectoryServices . ActiveDirectory. Domain] : : getcurrentdo- 
main() . Name, 
$Attr - $(throw Melyik attribútumot?") , 
$sValue - $null, 
$cValue - $(throw ,Mire változtassam?") 


) 


$root- [ADSI] ,LDAP://$domain" 
$Searcher - New-Object DirectoryServices .DirectorySearcher 
$Searcher. SearchRoot - $root 


if($sValue) 
( 
$buildFilter — , (£(objectClass-user) ($Attr-$sValue) ) " 
] 
else 
( 
$buildFilter — , (8£(objectClass-user) (!$Attr-"))" 


] 

$Searcher.Filter - $buildFilter 
$users - $searcher.findall () 
Foreach ($i in $users) 


( 
$dn-$i .path 
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$user - [ADSI] $dn 
write-host $dn 
$user.Put ($Attr, $cValue) 
$user.SetlInfo() 


Keresés idő típusú adatokra 
A címtárban nemcsak szöveges adatok vannak, hanem például dátum 
típusúak is. Ezekre nem triviális a keresés. Például keresem az utóbbi 


2 napban módosított AD-elhasználói objektumokat: 


PS C:PB $tól-get-date ((get-date) .AddDays (-2)) -Format yyyyMMddHHMWMss.OZ 

PS C:P $tól 

200830530110514.0Z 

PS C:B $searcher - New-Object directoryservices.directorysearcher 

PS C:B $searcher.searchroot - [ADSI] ," 

PS C:P $searcher.filter - ,(8(objectCategory-person) (objectClass-User) (when 
Changed:-$tól))" 

PS CB $result - $searcher.findal1() 

PS C:B $result 


Path Properties 


LDAP: //CN-János Vegetári ,0U-Demó,D... (samaccounttype, lastlogon, dscore... 


Az egészben a lényeg a $tól változó generálása, látjuk, hogy egy spe- 
ciális formátumra kell hozni a dátumot: ÉÉÉÉHHNNÓÓPPMM.OZ. 
Ilyen formázást szerencsére a get-date format paraméterével könnyen el- 
végezhetünk. 

Sajnos nem mindig ilyen egyszerű a helyzetünk, hiszen néhány dá- 
tumot jelző attribútum nem ilyen formátumban tárolja az időt, ha- 
nem , tick "-ekben, ketyegésekben. Ez 1600. január 1. 0:00 időponttól 
eltelt 100 nanoszekundumokat jelenti, mindez long-integer formátum- 
ban. Ilyen attribútum például a lastLogon, lastLogonlimestamp, last- 
Logoff, pwdLastSet. Ha ilyen attribútumok valamely értékére akarunk 
rákeresni, akkor elő kell tudnunk állítani ezt az értéket. Szerencsére 
a .NET keretrendszer ebben is segít. Elsőként nézzük, hogy dátumból 
hogyan tudunk ilyen long-integer-t előállítani: 


[5] PS CC: $most - get-date 
[6] PS C:W $most 


2008. június 1. 20:49:41 
[7] PS C:WS $most.ticks 
6334/9501812656250 


Látjuk, hogy elég a ticks tulajdonságát meghívni a dátumnak. 
Nézzük visszafelé, azaz hogy long-integerbből hogyan kapunk dátumot! 


Ez sem nagyon bonyolult: 


[8] PS C:We $MyLongDate - 633479501812656250 
19] PS C:W $mydate - New-Object datetime $MyLongDate 
[10] PS C:W $mydate 


2008. június 1. 20:49:41 


Egyszerűen kell kreálni egy dátum típusú objektumot, az objektum 
konstruktorának kell átadni ezt a számot, és ebből a .NET automati- 
kusan létrehozza a dátumot. 

Soós Tibor 
(soostigjb.hu) 
MCT, INSOFT — John Bryce Oktatóközpont 
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VVINDOWS 





(ÜNIFIED DATA) 
STORAGE SERVER 





NAS, azaz Network Attached Storage. Ebbe a kategóriába 
sorolhatjuk a Windows Storage Servert, ami jelenleg a 2003 R2 


családot erősíti, de talán még ebben az évben meglesz az új, 


2008-as változata. Mit tud egy ilyen Windows Server alapú 
NAS-megoldás? Mit jelent a , Unified" kiegészítése Menjünk le 
a gépházba, és érintsük meg a gőzölgő csöveket és szelepeket! 


ogyan készül a NAS-kiszolgáló? Íme, a recept: vegyünk egy fájlszerverkiszolgálásra op- 

H timalizált hardvert. Ebben a dobozban olyan módon illesztett alrendszereket és adatsí- 

neket találunk, amelyek az adott feladathoz és a várható terheléshez méretezett módon 

nem, vagy csak igen kis mértékben tartalmaznak szűk keresztmetszetet az adatáramlás útjá- 

ban. Telepítsünk fel rá egy olyan operációs rendszert, amelyik mind teljesítményében, mind 

szolgáltatásait tekintve kifejezetten a fájlkiszolgáló szerep betöltésére lett kialakítva. Ha ez az 

operációs rendszer a Windows Server család tagja, akkor azzal sem kell bajlódnunk, hogy egy 
újabb célgép vagy operációs rendszer kezelését, menedzsmentjét megértsük és elsajátítsuk. 

Az így kialakított kiszolgálót illesszük a hálózatba, engedjük rá tárhelyre és teljesítményre 


éhes (no és persze többnyire meglehetősen fegyelmezetlen) felhasználóinkat, és várjunk türe- 


[del hyánti 


Express Workgroup Standard Enterprise 


32 bit és 64 bit Igen Igen Igen Igen 


Hálózatok ] 7 Nincs korlát Nincs korlát 


CAL szükséges? Nem Nem Nem Nem 


Failover Clustering Nem Nem Nem Igen 
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lemmel. Átlagos esetben mi történik? Minél 
gyorsabb egy kiszolgáló, minél több a felhasz- 
náló, annál hamarabb megtelik még a leggi- 
gászibb tárhely is. Igen, kerül oda a munká- 
val összefüggő állományokból is, de sajnos 
leginkább filmek, zenék, képek és azonosít 
hatatlan forrásból származó applikációk - 
sokszor ugyanaz, több példányban. Mit tehet 
ilyenkor a rendszer gazdája? Van, aki a nyug- 
tatók hosszú tavi Batasalvaliszamolvadnikálbb 
beletörődik. Mások elkeseredetten lobbiznak 
az adattárolási házirend kialakításáért céges 
szinten, ami szigorúan büntetné a... 

Van viszont egy olyan, irigyelt típus, aki 
észre sem veszi. Hogyan csinálja? A dolog egy- 
szerűnek tűnik: megismerkedik a Windows 
Storage Server szolgáltatásaival. Alkalmazza 
a lehetőségeket, és néha-néha ránéz a ke- 
zelőfelületre, hogy minden úgy működik-e, 
ahogy megálmodta. 

És úgy működik! Nézzük meg, melyek a 
Storage Serverben rejlő lehetőségek! Először 


is jöjjön a , feketeleves"! 
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Tiltott funkcionalitás Példa 





RRAS, WINS 


Network-infrastruktúra 


Windows Server 2003 Network Load 
Balancing network driver 


Network Load Balancing 





Levelező- és csoportmunka- 
kiszolgáló, beleértve azok web alapú 
elérhetőségét is 


Lotus? Notes 


Vallomások — az igazság 3 perce 

A Windows Storage Server olyan, mint a töb- 
bi Windows Server. Azaz hogy - majdnem! 
Ugyanúgy van belőle Standard és Enterprise 
kiadás, de létezik még két , kisebb" változat 
is, különböző megkötésekkel (I. táblázat). 

A tisztesség úgy kívánja, hogy feltárjak 
néhány ,titkot", amelyeknek tudatában ér- 
demes elgondolkozni a bevezethetőség mód- 
járól vagy egyáltalán annak lehetőségéről. A 
Storage Server elsősorban fájlkiszolgáló. Eb- 
ben, mint látni is fogjuk, nagyon jó. Viszont 
van a Windows-világban néhány olyan tulaj- 
donság és szolgáltatás, amelyeket vagy nem 
tudunk feltelepíteni rá, vagy a licencben fog- 
laltak szerint nem szabad. Ez a lista a 2. táblá- 
zatban olvasható. 

A táblázat átböngészése után mindent tu- 
dunk, ami esetleg megköti a kezünket terve- 
zéskor. Érdemes azonban a ,tiltott" szolgák 
tatások körmére nézni, hiszen igaz, hogy a 
Storage Server nem lehet tartományvezérlő, 
de attól még örömmel válik egy már meglé- 
vő domain tagjává, és ugyanúgy végrehajtja 
a csoportházirendet, mint a többiek. Igaz, 
hogy nem telepíthetjük fel rá például az Ex- 
change szervert, de minden további nélkül 
képes ISCSI targetként tárolni a levelező- 
rendszerünk adatbázisát. 

A továbbiakban pedig következzenek a jó 
hírek! 

Ha a Storage Server mellett döntünk, szá- 
mos olyan szolgáltatást kapunk, amelyek nin- 
csenek, vagy csak részben vannak meg a töb- 
bi Windows-kiszolgálóban. 

Melyek ezek? 
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Exchange Server 2003 


SharePoint Portal Server 
Outlook Web Access 


Kivételek, megjegyzések 


DHCP-kiszolgáló engedélyezett 






Windows SharePoint Services 


engedélyezett 


SIS — Single Instance fáljrendszer 

Az első és talán a legfontosabb szolgálta- 
tás a olS, azaz a öinele Instance! fáljrend- 
szer. A fenti példában vázolt probléma, ami 
miatt a tárhely végtelen kapacitását kívánja 
az üzemeltetők többsége, egyszerűen megold- 


ható a segítségével. Arra szolgál, hogy a fájl 


rendszerben elhelyezett 
AZONOS " tattalműsállonmá 
nyok, amelyek különbö- 
ző könyvtárban és esetleg 
más-más néven mentet 
tek, ne foglalják a drága 
tárkapacitást a példány- 
számnak megfelelő meny- 


Gondoljunk 


csak egy e-mailben ka- 


nyiségben. 


pott vicces filmecskére, 
ami beérkezik 25 felhasz- 
nálónkhoz! Közülük mi 
nimum 18-an elmentik 
azt a valószínűleg sa hálós 
zati saját adatterületükre, 
a home directoryba. Ha 
ezek a könyvtárak a szer 
veren ugyanazon a kö- 


teten vannak, a SIS ezt 


észreveszi, és az állománynak egyetlen példá- 
nyát helyezi el egy rejtett, közös területre. A 
felhasználói mappába viszont pointert, lin- 
ket illeszt. Mennyi a megtakarítás? A vicces 
videó méretének 17-szerese! Mi van akkor, 
ha különböző néven mentik el az állományo- 
kat? Ugyanez, a SIS nem a fájlnevet, hanem 
a tartalmat figyeli. Nagyszerű! - kiáltanak 


felésokam "Ugyan már - mormognak" az 


DFS Load Balancing engedélyezett 


Exchange-rendszergazdák -, ilyen a levelező- 
rendszerben is van évek óta. Ez igaz, de a fájlb 
rendszerben? Bizony, a Storage Server NI FS- 
kötetein a SIS egy kattintással aktiválható! 


Hogyan működik a SIS? 


A SIS főbb komponensei közül az első és leg- 
fontosabb a SIS Groveler. Ez egy rendszer- 
szerviz, mely addig nem aktív, amíg az első 
köteten be nem kapcsoljuk a szolgáltatást. 
(Megjegyzendő, hogy a SIS egy időben ma- 
ximálisan 6 köteten képes működni.) A Gro- 
veler az, amelyik figyel. Figyeli az NTES fájl 
rendszer változásait, és folyamatos összeha- 
sonlítgatást végez a tartalmakban. Hú, nem 
túl nagy munka ez? Nyugalom, ésszel csinál 
ja. Minden állománytörzsben, valahol közép- 
tájon mintát vesz, és abból hash-t számít. Ha 
észlel két olyan állományt, amelyeknek az 
így képződött hash-értékei megegyeznek, só- 
hajt egyet, és nekilát egy igencsak derekas, 
bitszintű összehasonlításnak. Ha a két fájl 
tényleg megegyezik, felriasztja álmából leg- 
jobb barátját, a SIS Storage Filtert. Ez egy 


kernel módú fájlrendszeri komponens (dri- 





üddress B EA5IS Common Store 


fMame e 
Elia7abéd17-33a3-1 1dd-aü62-ü0ü3FFd4t4Ü8e , sis 
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El database. mdb 
edb.chk 
edb.lag 
edbtmp lag 
-$gravelini 
GarovelerFile 
MaxIndex 
res1.lag 

resz lag 
tmp.edb 





I. ábra 


ver), amelyik a Groveler kérésére a megjelölt 
állományokból egy példányt kimásol a SIS 
Common Store rejtett rendszerkönyvtárba 
az adott köteten, majd a fájlok eredeti helyére 
létrehozza az eredeti fájlneveknek megfelelő 
SIS Linket. A SIS Link az, ami kísértetiesen 
hasonlít a Unixrendszerekben és immár 
a Windows Vistában és Windows Server 
2008-ban" is használatos Symbolic Linkre, 


Microsoft TechNet 
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fnalyuziny uolume " 


fnaluziny Feparse puints... 


fnaluziny data... 


SENKIK ÉTÉ] data... complete. 
of volume "E:s" 
files: 

Link files: 2 

i link files: B 

326 KB 


bpace saved: 





2. ábra 


azzal a nagy különbséggel, hogy nem manuá- 
lisan jön létre, és nem igényel beavatkozást 
az eltűnése sem, mindent a SIS Storage Filter 
végez vele kapcsolatban. Mit észlelnek ebből 
a felhasználók? Egészen pontosan: semmit! 
(Az I. ábrán a SIS Common Store látható 
a működéshez szükséges adatbázissal és egy, 
már azonosított ,,.sis" kiterjesztésű állomány- 
nyal. Az eredeti könyvtárakban változatlan 
névvel mutatnak a SIS Linkek erre az állo- 
mányra. Az összefüggések pedig a database 
.mdb-ben rejtőznek.) - Ez igazán szép! - düny- 
nyögik a szkeptikusok. - De mi van a men- 
téssel? Hány példányban mentjük éjszaka az 
így tárolt állományokat? - Ezt bizony men- 
tőszoftvere válogatja, a SIS rendszerén nem 
múlik. A Storage Server tartalmazza a SIS 
Backup APLt, amelyen keresztül a mentés 
is megértheti a tárolás mikéntjét, a Common 
Store és a SIS Link összefüggéseit. Ha meg- 
érti, csak nyerünk vele: a szalagon tárolt ada- 
tunk fizikai valójában kevesebb, a mentés pe- 
dig gyorsabb lesz. Ez nem túl nagy baj, ugye? 
Végezetül gondoljunk a ( Hősök ) -re is egy 
kicsit, a rendszergazdákra, akik a SIS-t üze- 
meltetik. Milyen felülettel kényezteti őket a 
Storage Server?! Papír zsebkendőket elő, le- 
het, hogy sírni fogunk: a felület parancsso- 
ri! Első látásra elég meghökkentő, hogy egy 
ilyen horderejű funkciónak nincs minimum 
egy MMC-be épülő modulja, de ha egy kicsit 
is belegondolunk, talán nem is baj. Mit kell 
a SIS-en adminisztrálni? Alig valamit. Be le- 
het ugyan kapcsolni a grafikus felületen, az- 
után maximum statisztikákat nézegetnénk 
színesben... talán majd egyszer. Addig is itt a 
SISADMIN.EXE! 

A 2. ábrán a kiszolgáló Ex meghajtóján 2 
különböző könyvtárban 1-1 példányban la- 
kik egy 320 kilobájt méretű dokumentum. 
A megtakarítás mértéke meggyőző. Az ará- 


nyok hasonlóak akkor is, ha nem tesztrend- 
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fnaluziny Feparse points... 2 pFrocessed. BH not analyzed. 


(s Documents and Settingssádministratorssisadmin u ez 


fnalyzingy the 518 Common §tore directory... 

fnaluziny the §£I£§ Common §tore directory... 1 processed. 
sortiny 515 common store file list... 

süptiny 515 common store file list... complete. 


complete. 


complete. 


on STÖRÁAÁGESERŰÚER --- 


szerben vizsgálódunk, hanem élesben, adott 
esetben terabájtos nagyságrendű állomány- 
mennyiséggel. Egy utolsó kérdés merül fel 
bennem, bár már meg vagyok győzve: mi 
történik akkor, ha az egyik SIS Linkre kat 
tintva a felhasználó módosítja a saját ,pél 
dányát ? Ebben az esetben a Storage Filter 
elkészíti a felhasználónk állományának a va- 
lós "változatát a munkakonyvtárban: a 91s 
Linket pedig lebontja. Jó-jó, de mi lesz akkor, 
ha valaki kiad egy törlési utasítást egy SIS 
Linkre? Ebben az esetben csak a link törlő- 
dik. Viszont az utolsó link törlésével együtt 
a Common Store tartalmát képző valós fájl 
test is elutazik a Recycle Binbe. A SIS je- 
lentősége megkérdőjelezhetetlennek látszik! 
Honnan került elő? Most következik az utol 
só vallomás vele kapcsolatban. A RIS-ből. A 
Remote Installation Services környezetéből, 
ami már igen régóta része a Windows ki 
szolgálóknak. Emlékszünk a RIPrep image 
szerkezetére? Onnan emelték ki és tették 
önálló rendszerkomponenssé itt, a Storage 
Serverben. Ha valamire, hát a SIS-re tényleg 
komoly szükség lehet egy valamirevaló fájl- 
kiszolgálóban! Arról nem is beszélve, hogy 
a fájlrendszeri műveleteket gyorsító cache 
kihasználtsága is nagymértékben javulhat ál 
talatEelógyan" Ea az azonos tartalgúrtájlokat 
klienseink egyszerre nyitogatják meg, nem 
kell mindegyik példányt a gyorsítótárban 
tartani, bőven elég csak egyet - a Common 
Store könyvtárban lévő valós állományt. Ez 
pedig egy erőteljesen kihasznált kiszolgáló 
általános teljesítményére feltétlenül pozitív 


hatással van! 


File Server Management-funkciók 

Most pedig következzenek azok a kiváltságos 
szolgáltatások, amelyek - ellentétben a SIS- 
sel - a grafikus felületen elérhető felügyelet 
tel bírnak (3. ábra)! A Storage Serverben lé- 
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3. ábra 











tezik egy ollyan MMC beépülő modul, amely 
összefogja az extra funkcionalitás nagy ré- 
szét: a File Server Management, (?uota és 
Screening, DFS és NES, az Indexing és a 
SAN-eszközök kezelése lehetséges a menün 


keresztül, tessék választani! 


Ovota Management — ésszerűbben 

(2uota, azaz a felhasználónkénti tárhelyfog- 
lalás mérése és az evvel összefüggő intézke- 
dések a Windows Serverekben is vannak, az 
R2 óta pedig már nemcsak a komplett kötet, 
illetve partíció szintjén, hanem már könyv- 
tárra bontott korlátozást is beállíthatunk. 
Hogyan? Segíthetnek a (?uota Iemplate-ek, 
de saját elképzeléseinket is megvalósíthatjuk. 
A Management Console-ban elérhető lehető- 
ségek igen széles körűek. Csak a példa kedvé- 
ért: A kiválasztott könyvtárra alkalmazzunk 
egy template-et, amelyben megszabjuk a fel 
használók által lefoglalható terület mértékét. 
Saját template-et is menthetünk tetszés sze- 
rint. Eldönthetjük, hogy a benne foglalt érték 
valós korlát (hard limit), vagy csak monitoro- 
zásra való (soft limit). A figyelmeztetésre és a 


végleges limitre beállított százalékos értékek 
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4. ábra 


elérésekor különféle akciókat is foganatosít 
hatunk. Ezek között szerepel az e-mail (nem 
a , net send"!) a felhasználónak és/vagy az ad- 
minisztrátornak, valamint naplóbejegyzések 
és szkriptek futtatása mint opciók. A szkripte- 
lés érdekes lehetőséget rejt, meghívhatjuk ve- 
le a guota parancssori felügyeletét (Dir(9uota 
.exe), amit megfelelően paraméterezve auto- 
matikus guotawváltásra is használhatunk. 
Mire jó ez? A felhasználót a limit előtt több- 
ször is figyelmeztethetjük, majd amikor eléri 
a tényleges korlátot, még egy utolsó lehető- 
ségként egy kicsivel több helyfoglalást bizto- 
sító kvótát biztosítunk számára. Ettől kezdve 
viszont már nem vagyunk engedékenyek. Az 
abban foglalt limitet már tényleg komolyan 
kell venni (4. ábra)! Egy további lehetőség az 
Auto(uota, amely a limitált könyvtár meglé- 
vő és jövőbeni alkönyvtáraira is automatiku- 


san beállítja a kívánt korlátozást. 


File Screening — állománytípusok 
szűrése 

Örömhír! A File Screening segítségével rá 
tudjuk venni a Storage Servert, hogy az ál 
talunk megjelölt kiterjesztésekkel bíró tar- 
talmakat ne lehessen bizonyos területekre 
elmenteni. Jó, tudom, a kiterjesztések megvál- 
toztatása régi usertrükk, de számos felhaszná- 
ló nem bajlódik vele. Hogyan működik? A ke- 
zelőfelület nagyon hasonlít az előzőekben tár 
gyalt kvótáéhoz. Adjunk meg egy tetszőleges 
kötetet vagy könyvtárat, és állítsuk be, hogy 
milyen állománytípusokat nem látunk szíve- 
sen. Abban az esetben, ha a vizsgált típus, az- 
az az annak megfelelő kiterjesztéssel bíró fájl 


megjelenik, annak mentését a File Screening 


Ki 
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blokkolhatja, vagy csak nap- 
lóz, értesít, szkriptet futtat 
- igény szerint. Az 5. áb- 
rán láthatóak a template-ek, 
amelyeket  megváltoztatha- 
tunk, vagy saját elképzelé- 
seink szerint újakat is készít 
hetünk. Gondoljunk csak a 
cikk bevezetőjében említett 
rendszergazdára! A SIS, a 
(2uota és a File Screening 
együttes használatával olyan 
eszközök vannak a kezében, 
amelyekkel könnyen gátat 
szabhat a felhasználók fék- 


telen tárhelyhasználatának. 





Ha viszont (csak) tájékozód- 
ni szeretne a helyfoglalás számtalan jellem- 
zőjéről, akkor van egy roppant hasznos része 
is a File Server Managementnek - a Storage 
Reports Manager. Milyen riportokat tud ké- 
szíteni? A 6. ábra magáért beszél! 
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is. E cikk terjedelmi lehetőségein messze túl 
mutat a szerviz beállítási lehetőségeinek, opti- 
malizálásának és alkalmazhatóságának hatal- 
mas halmaza, de a Storage Serveren csak kap- 
csoljuk be egy adott területre, ezáltal az ott ta- 
lálható állományok a katalógusba kerülnek. 
Ha ismert szöveges típusokról van szó, ak- 
kor azoknak a tartalmában is kereshetünk 
- akár felhasználói oldalról is. Barátkozzunk 
meg vele, hiszen ebből a szempontból (lehet, 
hogy szentségtörés ilyet kijelenteni, de meg- 
győződésből teszem) a SharePoint alternatívá- 
ja! Jó, nincs verziókövetés és csili-vili felület, 


de szegény ember vízzel főz. 


DFS — az elosztott fájlrendszer és 

a megújult replikáció 

A Technet Magazin előző számában találha- 
tunk egy részletes ismertetőt a megújult DFS 
tulajdonságairól és működéséről, ezért ezt 
a szolgáltatást itt nem fejteném ki. Fontos 


szolgáltatás, de nem csak a Storage Serverre 





J File screen Template i acreeni 


Black, öudia and Yideo Files öctive 
Black. E-rnail Files öctive 
Black Executable Files öctive 


Active 


Block Image Files 


Monitor Executable and System Files Passive 


TAT Screen 
5. ábra 


Active 


A riport számtalan formában megjelenít 
hető, és rendkívül részletgazdag. Tortadiag- 
ramok és táblázatok segítenek felmérni a tár- 


helynek és fogyasztóinak jellemzőit. 


Indexing — keresés tartalomra is 

A Windows Server 2003/2008 is magában 
rejti az Indexing Service szolgáltatást, akár: 
csak a Storage Server. Igen ám, de meglátá- 
som szerint ezzel a szervizzel az üzemeltetők 
többsége kétféle kapcsolatban van: vagy nem 
használja, mert tény, hogy egy nagyon kevés- 
sé dokumentált és messze alulreklámozott 
dolog, vagy pedig feleslegesnek tartja, és az el- 
ső adandó alkalommal tiltja a működését. De 
miért? Akár komolyan is vehetjük a létét egy 
olyan fájlkiszolgálón, ahol állományok száz- 
ezreivel dolgozunk (ez bizony nem ritka). Egy 
kis memóriát áldozunk rá, és bízvást meghá- 


lálja. Meg bizony, már ha tényleg használjuk 


File Groups 
Black: öudia and videc Files 


nd Type 


Elock: E-rnail Files 

Elock: Executable Files 

Block: Image Files 

úarni Executable Files, System 


Black: Text Files 





jellemző. Benne van a Windows Server 
2003 RZ-változatokban ugyanúgy, mint a 
Windows Server 2008-ban. Funkciói közül 
röviden a virtuális hálózati adatszervezést, az 
Active Directoryval integrált elérhetőségeket 
és annak hibatűrését, a szinte bármire ráve- 
hető replikációs mechanizmusokat emelném 
ki, persze a teljesség igénye nélkül. Olyan 
- főleg sokszerveres, és esetleg sok telephe- 
lyes - környezetben, ahol az adatok nehezen 
átlátható módon vannak elhelyezve és cso- 
portosítva, komoly segítséget nyújt a felhasz- 


nálók számára. 


Services for NFS — látszódjunk 
NFS-kiszolgálónak! 

Nagyon fontos, hogy ez a szolgáltatás nem 
teljes SFU, azaz a Services for Unix, hiány- 
zik ugyanis belőle a gateway-tunkció! Miről 


is van szó? Ha a teljes SFU-t telepítjük egy 
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átlag Windows-kiszolgálóra, akkor három 
főbb kapcsolattípussal találkozhatunk. Ezek 
a Client for NES, a Server for NES és a Gate- 
way for NFS. Az első lehetőséget ad egy 


szerint leginkább diagnosztikai célból van je- 
len a ,de szeretnék adatterületeket látni az 
NES-kiszolgálón" kívánságot kielégíteni tudó 
Client for NFS komponens a maga parancs- 
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Edit Farameters... 


Ta configure a repart, 
hiahlahkt its label and 
check. Edit Farameters. 
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ff Csy IT Test 








6. ábra 


Unix/Linuxkiszolgálóhoz kliensként való 
csatlakozásra, a második - itt a legfontosabb 
- esetben a mi Windows-szerverünk NES-ki- 
szolgálóként (is!) funkcionál, a harmadikban 
pedig a Windowsz-szerver által az NFS-kiszol 
gálón látható adatterületeket az SMB-klien- 
sek (Windows-kliensek) számára teszi elérhe- 
tővé úgy, hogy azokon Unix/Linux:specifi- 
kus komponens telepítésére nem kerül sor. A 


Storage Server NAS és ezáltal fájlkiszolgáló 


sori mount utasításával együtt, amitől rög- 
tön egy másik világban érezhetjük magun- 
kat. A beállítások között a , User és Group 
Mapping" az első, hiszen a Unix rendszeré- 
ben autentikált felhasználókat a saját környe- 
zetünkben is reprezentálnunk kell valahogy. 
Hja, Kerberos Realm Irust kapcsolat híján 
ez kézenfekvő megoldásnak látszik. Ezután 
következhet az NFS-megosztások kialakítá- 
sa, a jogosultságok definiálása, majd végül 


a teszt: el tudják érni az 
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szerepkörével így elsősorban a ,de szeret 
ném kiszolgálni a Windows-kliensek mellett 
az esetleges NSE.klienseket is" - Server for 


NES - képesség egyeztethető össze. Érzésem 


MÁJUS-JÚNIUS 


55-63 Microsolt Services For MF-5 
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NES-kliensek a számukra 
közzétett  adatterületeket? 


El bizony! 


Storage Manager for 

SANS — egységesített 

storage-kezelőfelület 

VDS, azaz Virtual Disk 
Service. Mire jó ez nekünk? 
Vizsgáljuk meg a szerverün- 
ket! Van benne RAID-ve- 
zérlő? Nincs? Csatlakozik 
közvetlenül a Storage Area 
Networkbe Fibre Channel vagy iSCSLeszkö- 
zökkel? Nem? Ebben az esetben maradjunk 





a jól megszokott Disk Managementnél, azt 


a helyi 1-2 diszket biztonsággal elkezelget 


Cs Re 


hetjük vele. Viszont egy olyan környezetben, 
ahol a tárhelyre, sőt annak teljesítményére 
és hibatűrésére komoly hangsúlyt fektetünk, 
hamarosan azt vesszük észre, hogy szép las- 
san kezdenek elszaporodni a fent vázolt kom- 
ponensek: RAID-vezérlők és SAN elérhe- 
tőségű diszkralrendszerek. Sok esetben ezek 
több, különböző gyártó dobozai és megoldá- 
sai, mindnek sajátos kezelőfelülete és kezelé- 
si módszertana van/lehet. A VDS egy olyan 
szabványosított illesztőfelület, amelyik meg- 
adja a lehetőséget a külső storage-gyártóknak 
arra, hogy a portékájuk menedzsmentjét beil- 
leszthessék egy, a Windowsban egységes rend- 
szer alá. A gyártónak , nincs más dolga", mint 
az adott storage eszköz mellé csomagolni egy 
úgynevezett VDS Providert. Ezt telepítjük a 
rendszerünkbe a VDS alá - és máris műkö- 
dőképes a Storage Manager for SANS (8. 
ábra)! Egy időben akár több VDS Provider is 
lehet a rendszerünkben, így ugyanarról a fe- 
lületről hozhatunk létre mondjuk Logikai 
Unitot egy IiSCSI Target mögött, vagy növel 
hetjük menet közben a méretét egy virtuális 
diszknek a Fibre Channel Arrayben. Fontos 
megjegyezni, hogy a szerverre telepített VDS 
Provider segítségével nemcsak azokat az ob- 
jektumokat változtathatjuk, amelyek a mi 
szerverünk számára lettek , prezentálva" a 
SAN-ban, hanem az adott storage-ban az 
összeset! Lehet, hogy a felület barátságos és 
egységes, de megnyitásával már a SAN-admi- 
nisztrátorának felelőssége is a mi vállunkat 
nyomja - csak óvatoSAN! A VDS Provider 
megszerzése sok esetben némi kutatómunkát 
igényel. A gyártói weboldalak, dokumentá- 
ciók és az adott diszkalrendszer mellé adott 


CD-k, DVD-k sokat segítenek! 


Windows Unified Data Storage 
Server 

Unified? Mit és mivel egyesít a Storage Ser- 
vernek ez a verziója? Először is nem külön 
verzió. De hát mégis az, hiszen a neve... Hogy 
is van ez? Öntsünk tiszta vizet a pohárba! 
Bármelyik Storage Serverkiadásból (lásd I. 
táblázat) készíthetünk Unified Data Storage 
Servert úgy, hogy megvesszük és feltelepítjük 
a , Unified Add-on" kiegészítést. Aha... és ab- 
ban mi van? Mi is? Hát az iSCSI Target! Az 
ISCSI Target szerepkör viszont már egy má- 
sik kategória, azaz nem NAS, hanem SAN! 
Szinte az összes eddig felsorolt szolgáltatás a 


szerverünk fájlkiszolgáló-képességét dicsérte. 
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Lássuk csak... A fájlszerverhez, azaz a NAS- 
hoz kik csatlakoznak? Jellemzően a felhasz- 
nálók! Hogyan, milyen módon? Hálózaton. 
Hálózaton, ami a modell szerint network 


kapcsolat. Host kapcsolódik hosthoz, Linux 
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ciós rendszer része, más gépekre ingyenesen 
letölthető), majd felkeresi a rendszer gazdája 
által benne beállított ISCSI Target Portalt 
(9. ábra). A Portal jelen esetben nem más, 


mint a mi Unified Data Storage Serverünk, 
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Windowshoz, 
az adat elérése pedig jellemzően fájlszintű. 
Hogy működik mindez a SAN-ban? SCSL 
adapter SCSI Storage-hoz, host egy szalagos 


applikáció  applikációhoz... 


egységhez, host egy diszkhez. Jellemzően a 
szerver az adattárhoz. Ez pedig maga a csa- 
tornakommunikáció! Az adat elérése pe- 


dig ebben az esetben eAkkor mit is egyesít 


azaza rajta tütörSESlészolgáltatássaN TE TÉE 
hat az Initiator a Target Portal mögött? Kis 
szerencsével Targetet. A Target nem más, 
mint egy olyan logikai objektum, amely az 
ISCSLkiszolgáló számára leírja, hogy mely 
kérelmezők mely logikai (virtuális) diszkek- 
hez férhetnek hozzá. Így magától értetődő, 
hogy az iSCSI SAN-ban minden kérelme- 
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9. ábra 


a Windows Unified Data Storage Server, 
amelyik abban más, mint a többi Storage 
Server, hogy telepítünk rá iSsCSI Target kom- 
ponenst? Igen, az adatok fájl és blokkszintű 
elérhetőségét! A NAS és SAN kiszolgáló-sze- 
repköröket. Ezt jól megfejtettük! Vizsgáljuk 
meg, hogy állja meg a helyét szerverünk iS- 
CSI Targetként! 


Microsoft iSCSI Target 

Hisztázzúmk aláptósgalmakátsaz as EST köme 
munikáció rendszerében. Melyik a kliens? Az, 
amelyen úgynevezett iSCSI Initiator kompo- 
nens van. Ha Windows Server 2008 kiszol- 
sálónk van, akkor az [nitiator az operációs 
rendszer része. Más - régebbi - kiszolgálók 
esetén nyugodtan telepíthetünk ilyet, ingye- 
nesen letölthető a Microsoft oldalairól. Hova 
csatlakozik egy Initiator? Először is jól nevelt 
módon regisztrálja magát az iSNS kiszolgáló 
adatbázisába (Windows 2008-ban az operá- 


32 


ző szerver számára a kiszolgálóban létrehoz- 
zunk egy targetet. A target mögé csatlakoz- 
tatott virtuális diszkeket fogja a kérelmező 
SS ISESlEcsatormakapcsolatom e "sajat "diszk 
ként a Disk Managementben megjeleníteni. 
Az, hogy minden kérelmező egy saját targetet 
lát, és természetesen (csak) a target mögé csa- 
tolt diszkeket, nem más, mint a SAN-okban 
olyan jól bevált prezentáció (selective storage 
presentation, LUN masking) módszerének 
alkalmazása. A targethez való csatlakozáskor 
a kiszolgáló azonosítja a kérelmezőt (lehető- 
ségek: IP, ION, FODN, MAC), autentikációt 
is beállíthatunk (CHA P), és ha minden stim- 
mel, a virtuális diszkekhez való hozzáférést 
biztosító zöld lámpa kigyullad. Végezetül ta- 
pogassuk meg a kérelmezők felé prezentált 
virtuális diszkeket! Mik ezek? Ugyanolyan 
VHD állományok, mint amilyenek a vir 
tualizációs rendszerekben is széles körben 
elterjedtek a Virtual PC-től a Hyper-V-ig. Az 


AS 


MS iSCSI kiszolgáló ezekből snapshotolka)t 
is képes készíteni, illetve helyi csatolásra 
(mount) is lehetőség van. Támogatja a targe- 
tekhez való redundáns hozzáférést is, ha a ké- 
relmezőoldalon feltelepítjük és konfiguráljuk 
a MultiPath [/D (MPIO) komponenst. A hi 
batűrő SAN-kapcsolatok kialakítása ebbe az 
irományba terjedelmi okokból nem fér bele, 
sőt egy újabb cikkért kiált. Kedvcsinálóként 


viszont - remélem - megállja a helyét. 


Storage Server-szerepkörök 

A Storage Servert a felé irányuló kapcsolatok 
tekintetében különböző kategóriákba sorol 
ják. Zárószóként nézzük át ezeket! Jellemzően 
háromféle logikai szerepet vállalhat. Az első 
a NAS-kiszolgáló. Ebben az esetben kiszol 
gálónk a saját diszkjein fellelhető adatokból 
juttat jószívűen a klienseknek - akárcsak 
egy fájlszerver. Sokszor elhangzik azonban 
a SAN Gateway fogalom is a mágusok szá- 
jából, amitől ne jöjjünk zavarba: ez ugyanaz, 
mint a NAS, csak ebben az esetben a Storage 
Server nem a saját helyi diszkjein, hanem az 
általa a SAN-kapcsolatok valamelyikén el 
érhető diszke(keln tárolja a felhasználói ál 
lományokat. A harmadik fogalom a SAN 
Target, itt a Windows Storage Server - a 
Unified Add-On kiegészítéssel - blokkszintű 
diszkelérést biztosít, jellemzően a többi ki 


szolgáló részére. 


Szeretnék Storage Servert! 
Hogyan jutok hozzá? 
Az a módszer, hogy földi halandóként bebalk 
lagunk az első szoftverdisztribúcióba, és meg- 
villantjuk dombornyomott bankkártyánkat 
- sajnos nem működik. Két járható út van. 
Az egyik, hogy neves gyártók előre telepített 
, NAS Appliance" kategóriájú célgépét meg- 
vásároljuk. Többségük még ki is egészíti a 
szolgáltatások körét némi adatmentő-, adat 
replikációs- vagy felügyeleti szoftverrel. A 
másik módszer, hogy mi magunk rakjuk ösz- 
sze a NAS-kiszolgálót. Kössünk szerződést a 
Microsoft Embedded termékeket forgalmazó 
csatorna képviselőjével! Így az általunk gyár- 
tott (összerakott) hardverre telepíthetjük a 
Storage Servert, és tovább értékesíthetjük a 
végfelhasználóknak. 
Székács András 
(andras(Dedupro.hu) 
MCSE, MCT, MCTS 
Számalk Zrt. 
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IAG 2007 


Távoli elérés egy igazi nagyvaddal, 


SSL VPN alapon. 





endszereink távoli elérésének hagyományai messzire nyúlnak vissza az időben - és ez a 

múlt igencsak küzdelmesnek bizonyult, nem vitás. Ennek ellenére a távoli elérés vonzó 

lehetőség az informatika világában, amit ha józan ésszel nézek, akkor nem is értek, hi- 
szen például a vasutasok nem viszik haza a munkát, mi meg szinte nem is bírjuk ki anélkül, 
hogy otthon, illetve bárhol máshol ne férjünk hozzá például a leveleinkhez vagy más erőfor- 
rásainkhoz. 

Kezdetben, az analóg modemes korszakban nem kevés nehézség állt előttünk, iszonyú drága 
volt és borzalmasan lassú (amikor én kezdtem, az első modemem 9,6 Kss volt, de én viszony- 
lag későn kezdtem, és még nem számítok nyugdíjas korúnak), hardveresen erősen korlátozott 
volt a kapcsolatok száma, és a maximum szolgáltatás, amit komoly kompromisszumok nélkül 
használhattunk, az a postaládánk elérése volt (persze csak POP3, vagy inkább IMAP, semmi 
extra), meg még esetleg a telnet, no meg az automatikus visszahívás lehetősége, és az ezzel járó 
széttárt kezek a céges telefonszámlák érkezésekor. Aztán jött az ISDN, és ekkor a kapcsolódás 
fő jellemzője immár nem az egyperces, idegborzoló sípolás volt, a sebesség pedig nőtt, ha ügye- 
sek voltunk a multilink segítségével akár az akkor csillagászati mértékűnek számító 128 K-s se- 
bességet is összekalapálhattuk. Így aztán már több belső szolgáltatás használata is belefért, sőt, 
az ISDN-központok révén akár a felhasználóknak is bátrabban ajánlgathattuk a távoli elérés 
lehetőségét, anélkül, hogy ez mély fájdalmat okozott volna nekünk. De nagyjából ekkor két új 
probléma is felmerült: 

1. Kliensoldalon bonyolult egy kapcsolatot létrehozni a megfelelő szaktudástól el nem vakítva. 
2. Ekkor már az internet nem az volt, ami korábban: enyhén szólva is erősen ügyelni kellett a 
biztonságra. 

Az első pont nehéz ügy, de a másodikra megoldás volt (és ma is az) a klasszikus VPN haszná- 
lata (persze a távoli elérés tiltása is jó módszer, de talán nem elég kreatív), amely új dimenziókat 
nyitott. A távoli ügyfél számítógépe saját internetkapcsolat birtokában, teljes körű résztvevője 
lehetett a belső hálózatnak, gyakorlatilag a megszokott sávszélességen kívül minden lehetősé- 
get megkaphatott, amit a benti hálózatban élvezhetett - és ezt bárhonnan, ahol volt internet 
elérés. Ezzel aztán át is estünk a ló túlsó oldalára, hiszen a vezetékes hálózatban, a tartományi 
rendszerben hatékonyan működő Csoportházirend, a kötelező frissítések letöltése és telepítése 
(például WSUS9S), az esetleges belső központi antivírusrendszer adatbázisa és sok más korláto- 
zó, rendet teremtő megoldás alól a VPN-ügyfelek mentesültek, ráadásul tényleg, miért is kell 
elméletileg mindent elérnie kívülről egy átlagos felhasználónak? Nem kell, de nem volt rá élet 
képes megoldás, még a Windows Server 2003-ban bevezetett, majd az ISA 2004-ben , kifénye- 
zett" karanténszolgáltatás sem volt az. Ma már más a helyzet, az NLA miatt a távoli Vistánál le- 
hetséges dinamikusan a Csoportházirendet alkalmazni, a Windows Server 2008-ban debütáló 
Network Access Protection mindenféle közegben (DHCP, IPSec, VPN, RDP, 802.1x) megállja 
a helyét, sőt a teljesen újnak számító Terminal Server Gatewayen beállított házirendek segítsé- 
gével megszabhatjuk, hogy ki, mely gépekről mely belső gépeket érheti el. 

Aztán a sávszélesség egyre csak nőtt és nőtt, immár az intranetportálok, a , gazdag" szolgál 
tatást nyújtó belső kiszolgálók elérése sem volt lehetetlen, és a tűzfalbarát elv mentén elkezdtek 


megjelenni a HITPS porton működő vagy abba beágyazott szolgáltatások (xxx over HTTPS), 


MÁJUS-JÚNIUS 


de a megmaradt régiek mellett újabb problé- 

mák is jelentkeztek: 

a Még mindig bonyolult, sőt még bonyo- 
lultabb beállítani a távoli elérést, a VPN 
mellett gondoljunk az Outlook RPC over 
HTIPS-re vagy a ISG kliensoldali beállí- 
tására, vagy akár csak arra, hogy a felhasz- 
nálónak minden egyes alkalommal először 
kapcsolódnia kell a VPNikon segítségével. 

a Még az olyan komplex VPN-szerverekkel, 
mint az ISA 2006 sem tudunk igazán lé- 


nyegesen változtatni azon, hogy a külső 





KEKTTKTESTETT NN 3] 
General ] User Groups Computer Group ] Alowed Ports ] 


Users can connect to network resources in a 
Gateway. 


somoer aroue through TS 
by doing one of the following: 


C Select an existing Active Directory security group. 
E This group exists in Local Users and Groups or in Active Directory Domain 


C Select existing TS Gateway-managed computer group or create a new one 


JESSZE EZTET Browse l 


SEN 


(5 Alow users to connect to any network resource 


3 














TSG Resource Authorization Policies, azaz mely gépeket 
érhetjük el a hálózatban? (1. AD csoport alapján, 2. TSG 
csoport alapján, 3. bármelyiket) 


ügyfél több fizikai elérést kapjon a belső 
hálózatban, mint amennyi kellene. 

a Továbbra sem biztonságos az internet, és 
bár a VPN és a HTTPS ezt a problémát 
többnyire áthidalja, de sajnos nem lehet 
mindenhonnan a szokásos VPN.protokol 
lokat használni (erre viszont passzolhat a 
szintén a Windows Server 2008-ban meg- 
jelent SSIP VEN típus - pongyolán fogak 
mazva: , VPN over HTTPS" -, de csak erre). 

a A PPIP VPN-nél lényegesen többet nyújtó 
megoldás az L2TP/IPSec, de ehhez az ösz- 
szes köztes résztvevőnek támogatnia kell 
ezt, és például a NAT vs. integritás prob- 
lémára megoldást nyújtó NATTraversalt, 
beleértve az OS-eket is (az XPSP2 előtt ez 
nem volt jellemző). 

a Nemcsak a HTIP/S-xn elérhető szolgáltatá- 
sokat szeretnénk használni, és persze nem 
akarunk és nem is lehet x darab kliens- 


programot telepíteni minden egyes távoli 
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elérésre használt gépre, hogy aztán VPN- 
en kapcsolatba kerülhessen a belső, nem 


HTIP alapon működő kiszolgálókkal. 


szöl bele egy SSL-lel védett alagútba, a másik 
oldalon pedig ezt egy RPC/HTTP-proxy fo- 
gadja, majd szépen továbbítja az Exchange-ki- 


szolgálónak. 
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Socket / port forwarding. 
A kliensoldali alkalmazás fi- 
gyel, majd a spéci portra/soc 
ketre igyekvő forgalmat (pél 
dául TCP 257110) átitányítja 
egy SSLlinken keresztül az 
SSL VPNiátjáróhoz, amely az- 
tán szépen kibontja az alag- 


útból, és elküldi a levelezőki- 





Az IAG 2007 komponensei és felépítménye 


Nos, egy ideális (azért csak óvatosan ezzel a 
szóval) megoldásnak tehát minimum a követ 
kezőket kellene nyújtania ezen a területen: 

a Problémamentes, biztonságos kapcsolódás 
bármilyen tűzfalon és hálózati eszközön 
keresztül. 

a A szolgáltatások ügyfélbarát megjelenése, 
mindenféle kliensoldali beállítás nélkül. 

n Univerzális (azaz nem csak webes) alkal 
mazáspublikálási lehetőség az üzemeltetők 
számára. 

A lehetséges megoldás már egy ideje itt van 
köztünk, neve kb. annyi van, mint Ságvári 
Endrének, de a legjobb valószínűleg az SSL 
VPN, de még ennél is fontosabb, hogy már 
kilépett a gyerekcipőből, azaz 
most már tényleg ideje megis- 
merkednünk vele. Kezdetben 
viszont az eszközeink (akár 
hardveres, akár szoftveres te- 
rületen) kevésbé voltak sokol 
dalúak, így az ismerkedést kezdjük meg első 
körben az SSL VPN alapjául szolgáló (vagy 
ezekhez nagyon hasonló) technikai megoldá- 
sok választékával: 

Reverse proxy megoldások a webes alkal: 
mazások számára. A legjobban ezt az ISA-ki- 
szolgálók webpublikáló szabályai mutatják, 
amelyeknek semmi közük sincs a VPN-hez, 
van viszont az ezen a területen alapfeltétel 
nek számító előzetes hitelesítéshez, illetve az 
URL-ek átirányításához, ergo, a különböző 
web filterek igencsak hozzájárulnak a bizton- 
ságossághoz, sokkal jobban, mint egy átlagos 
reverse NAT-megoldás. 

Protocol tunneling. Egy SSL-kapcsola- 
ton belüli alkalmazásprotokollkapcsolat. 
Mindenki ismeri a jó példát: Outlook RPC/ 
HTTP-kliens RPC/MAPLIlhívásokat gyömö- 


Ke 


szolgálónak. 
Ezek 


cióin kívül ma már a valóságban sokkal több 


esetleges  kombiná- 

mindent is elvárhatunk egy komplex SSL 

VPN-eszköztől. Konkrétan a következőkre 

gondoljunk: 

a Tunneling. Minden SSL VPNiátjárónak 
képesnek kell lennie arra, hogy a webes és a 
nemwebes alkalmazások összes forgalmát 
bele kell tudni pakolni a HTTPS sessionbe. 

a Kliensoldali biztonság. Akármilyen álla- 
potú kliens nem érheti el a publikált szol 
gáltatásokat, épp ezért működnie kell egy 
ún. endpoint detectionnek, amely a felté- 
teleink alapján képzett biztonsági házirend 
pontjaival szembesíti a klienst, és ha nem 


felel meg, nem kaphat hozzáférést (lásd 






o 


Maga az eszköz, amin az IAG fut 


VPN-karantén, de inkább a NAP vagy in- 
kább egy, a kettő közötti megoldás, ám fi- 
nomabb ellenőrzési lehetőségekkel). 

a Előzetes hitelesítés. Nincs közvetlen hite- 
lesítés a belső szerverekkel, az SSL VPN-át 
járó kéri be a hitelesítési adatokat, elbandu- 
kol a belső szerverhez, és továbbadja ezt az 
információt, majd bekéri az adott erőfor 
ráshoz szükséges jogokat is, és ezzel vándo- 
rol vissza a külső ügyfélhez - akkor is, ha 
nem egy webes protokollról van szó. Ráadá- 
sul kismillió névtérből tudnia kell ezt. 

x Jogosultság-ellenőrzés. Magának az SSL 
VPN-eszköznek is képesnek kell lennie 
előzetesen engedélyezni vagy megtagadni 
a hozzáférést a hostolt alkalmazásokhoz, 
akkor is, ha az egy másik kiszolgáló segítsé- 


gével érhető el. 
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an Portál. Az egyszeri, űrlapos belépés után a 
felhasználó egy könnyen kezelhető webla- 
pot lát, rajta az összes alkalmazással és hoz- 
záférési lehetőséggel, amelyeket elérhet, de 
tényleg csak azokkal, amelyeket elérhet. 
Így a felhasználónak csak ezt az egy URL-t 
kell megjegyeznie, és a szintén kötelező 
SSO miatt (Single-Sign On) elég egyszer 


(interaktívan) belépnie. Ráadásul követel 


TETTE ee a ézte TT ein i 1 ei 
Operating System Supported Browsers 


Windows XP, 
Windows Server 2003 





Internet Explorer 6, Internet Explorer 7, 
Netscape Navigator 7.1.x, Netscape 
Navigator 7.2.x; Mozilla 1.7.x; Firefox 1.0.x 
Windows Vista 


Windows Mobile 2003 
for Pocket PC 
MacOS X 


Microsoft Internet Explorer 7, Firefox 2.0 


Pocket Internet Explorer 


Safari 1.2.4, Safari 1.3, and Safari 2.0, 
Netscape Navigator 7.1.x, Netscape 
Navigator 7.2.x; Mozilla 1.7.x; Firefox 
1.0.x; Camino 0.83 


Netscape Navigator 7.1.x, Netscape 
Navigator 7.2.x; Mozilla 1.7.x; Firefox 1.0.x 


Linux 
(Red Hat, SUSE, Debian) 











A lista igazán nem mondható szűknek. . . 


mény, hogy ezt a portált a lehető legna- 
gyobb mértékben lehessen testre szabni az 
üzemeltetők által. 

a Szűrés az alkalmazásrétegben. Áz egy iga- 
zán előremutató elképzelés, hogy a sok: 
sokféle hálózati forgalmat és protokollt 
egy tűzfalbaráttal helyettesítsük (legalább- 
is a szervezetünk belépési pontjáig), de ha 
logikusan belegondolunk, akkor ez azzal is 
jár, hogy minden más káros vagy nem en- 
gedélyezhető alkalmazás - spyware, trójai 
stb. - is erre fog rákapni. Ebben az eset 
ben a dilemma nagy: vagy engedélyezzük 
szűrés nélkül a HTIP/S-portokat, és ak- 
kor a webes MSN-), ICO-t, a torrentalb 


kalmazásokat és sorolhatnám a további 
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Az ikonokra kattintva indulnak az alkalmazások 





o Contoso Self Help 
CONLOSOI  Configure Cfient Computer 








példákat azokra, amelyek vagy a népszerű 
portokon, vagy a HITP/S folyamatba be- 
ágyazódva működnek, vagy ha nem, ak- 
kor bentről sincs netezés. Bármennyire is 
szimpatikus az utóbbi, ezt nem tehetjük 
meg, ergo, gondoskodni kell egy komoly 
HTTPfilterről, illetve emellett természete- 


Microsoft TechNet 





met 
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sen az SMIP-, POP3-, RPC-, IMAP4 stb. 
portok megfelelő szűréséről is. 


Szóval ma már szerencsére sokat várha- 


tunk el egy korrekt SSL VPN-eszköztől, és 


a https:/fiag.contoso.com - System Information - Microsoft Internet Explorer 


és a Whale Communications együttműködé- 
séből, 2007 tavasza óta létezik egy Windows 
Server 2003 R2 alapon működő, Internet 
Application Gateway 2007 nevet viselő SSL 

VPN-eszköz, amely - mint az 


architektúrából látható - az 





Whale 7 
Communications System Information 
FA LELTE IT SZIG TETO 





Whale Client Components 
vwhale Component Manager v (3,7,195,0) 

Endpoint Detection v (3,7,195,0) 

SSL Wrapper v (3,7,195,0) 

SSL Wrapper Java ápplet NA 

Socket Forwarder 

Network Connector 


öttachment Wiper TM v (3,7,195,0) 


önti-virus 
Personal Firewall 
Operating System 
Browser Version 
User Agent 


2K3 Version: Nfá Not Running 


Internet Explorer 6 


,NET CLR 2.0.50727) 
Sun JRE Version NyA 
Dornain WORKGROUP 
Certified Endpoint x 
Privileged Endpoint v 


To refresh this page, please log out then log in again. 





LEzts 


Részletes infók a kliensről 


mivel ez egy jó ideje létező technológia, már 
számos gyártó (Juniper, Celestix, F5, Check 
point, Cisco, Citrix, SonicWall stb.) készít is 
ilyen eszközöket, pontosabban önmagában 
a szoftvert (ez a ritkább), vagy együtt a hard- 
verrel, amelyet ilyenkor , appliance"-nek hí 
vunk, és ez tipikusan egy-egy rackbe szerel 
hető, célhardvert jelent, a speciális szoftver- 
rel, extrákkal és persze egy megfelelő OS-sel 
együtt. 

(Megjegyzés. Az , appliance" kifejezés nem 
ismeretlen az ISA-rendszergazdák számára, 
ISA 2004/2006 appliance-ből is van szá- 
mos, a HP-tól a Celestixig jó néhány gyár 
tó készít szenzációs, Windows Server 2003 
alapon működő, az ISA 2006 speciális, ún. 
Workgroup Editionjét tartalmazó eszközt, 
szokás szerint spéci filterekkel, bővítmények- 
kel - például Websense/SurfControl termé- 
kek, vírusirtók stb. Jómagam is szeretgetek 
egy pár hónapja egy Celestix MSA2000-tt, 
igazán nagy élmény.) 


Visszatérve az eredeti témához, a Microsoft 


3 Whale Communications Intelligent ápplication Gateway - Portal - Microsoft Internet Explorer 
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Wwhale Communications Intelligent Application Gatevay 


LSP: 47 (3,7,195,0) NSP: v/ (3,7,195,0) [Basic] 

client: vf (3,7,195,0) Driver: wf (3,7,195,0) Not Running 
MsSForefront 1.5.1937.0 (Updated;: 1/9/2007 4:25:08 PM) 
Windows 2003 Advanced Server 5.02.3790, Service Pack 1 


Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; ,.NET CLR 1.1.4322; 


This site is protected by the Wwhale Cornmunications Intelligent Application Gateway. 


OS-en kívül több ismerőst is 
tartalmaz, például az IIS-t és 
az ISA-kiszolgálót. 

Ez a termék kifejezetten 
089 szintén csak az említett ,ap- 
pliance" formában kapható, 
azaz csak a hardverrel egybe- 
építve szállítják (így nem is 
egy Microsoft logóval ellátott 
dobozt kapunk, például itt, 


az asztalomon egy Celestix 





z WSA 3000-es hever, a fotót 


lásd a 34. oldali képen), az 
OEMc-cég által előtelepítve. Az 


ára többnyire igencsak borsos, ám 





ha átgondoljuk, hogy mi mindent 


MI microsoft internet security and Acceberatson server ZVUt 
File Acton View Help 


s 
ks ml 


ban látszik, hogy mivel ez egy belső/védett 
kliens, ezért az alap intervallumot 24 órára 
állítottam. 

A böngészőablak tartogat még jó pár kelle- 
mes szolgáltatást a menüsorban - a nem ad- 
min felhasználók számára is. Többek között 
lehetséges a jelszóváltás, az esetleges - birto- 
kunkban lévő - további jogosultság beadago- 
lása, az egyéb, nem ezen a kiszolgálón publi- 
kált alkalmazások tallózása, a nagyon alapos 
rendszerinformációk listázása, a portálaktivi 
tás részleteinek megtekintése és az e-mail-kül 
dés az adminnak. 

A portál mint objektum nagyon részlete- 
sen konfigurálható, könnyedén testre szab- 
ható, és egyszerűen létrehozható a különbö- 
ző igények alapján. Az első portált a szervezet 
maximálisan meglévő szolgáltatásai alapján 
állítottam be a belső felhasználók számá- 


ra, míg a másodikat, jóval szigorúbban, ke- 











tartalmaz, és megismerjük alapo- 
san, akkor már nem is tűnik majd 
olyan soknak. 8 enm 

Így néz ki egy SSL VPN-esz- 
köz, amelyben belül egy IAG 2007 
munkálkodik (felhívnám a figyel 
met a jobb oldalon látható tekerő- 
gombra - jog -, ezzel első lépés- 
ként a TCP/IP-konfigurációt fog- 
juk majd beállítani). 
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Policy Editing Tasks 


System Policy Tasks 
AP Edit System Policy 
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(e) Import system Pokcy 


Related Tasks 

I Define 17 Preferences 
(€) Export Frewreli Pulcy 
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Általában a használatbavétel el 
ső lépése az OS és az alkalmazások 
telepítése, de mivel ezzel itt nem kell 
foglalkozunk, helyette tekintsük meg inkább a 
támogatott kliensek (böngészők) listáját. 


A portálok 

Ha szeretnénk látni már egy portált, akkor 
csak a böngészőre van szükségünk, meg a 
portál URLJére, ezek birtokában el is jut 
hatunk az adott kezdőlapra, amelyen egy űr- 
lap fogad majd bennünket. 
Bejelentkezünk, majd a kli 


ens megbízhatóságától függő- 
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en (például külső gép, belső 


00-5540. E? logot 
gép) különböző listát kapunk 
az elérhető alkalmazásokról 
és szolgáltatásokról. Sok más 
opció mellett a rendszerben 
eltölthető maximális időtar- 


tam is része lehet ennek a be- 





Szűkített lehetőségek a partnerportálon 
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állításnak, a jobb felső sarok- 





Előregyártott szabályok az ISA-ban 


vesebb erőforrást megengedve egy elképzelt 


partnercég számára (természetesen különbö- 


ző URL-lel rendelkeznek). 


Az ISA Server 
Ha viszont az ismerkedést nem a portállal, 
hanem direktben az IAG gépen kezdjük, ak- 
kor a kíváncsiságtól vezérelve megtekinthet 
jük rögtön az IAG mögött álló ISA Servert. 
A faszerkezetben sok meglepetés nem lesz, 
ugyanis egy teljesen szimpla (jelen esetben 
egy Standard) ISA 2006 MMC konzolt lát 
hatunk, egyetlen igazi különbséggel, amely a 
tűzfalszabályoknál jelentkezik, de ott viszont 
nagyon. 

A képen számos tűzfalszabály látható, 
azért, mert ez már egy működő IAG 2007 
gép, viszont magában az ISA-ban manuálisan 


nem hozunk létre szabályokat, ezt az IAG a 
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konfigurálása közben automatikusan meg- 
teszi. Szóval sok esetben a szolgáltatások egy 
részénél valóban az ISA van a háttérben, de a 


beállítása automatikus. 


IAG Configuration 

Ha már az IAG gépen vagyunk, nézzük meg 
az üzemeltető számára legfontosabbat, azaz 
azt az alkalmazást, amellyel az eddig ismer- 
tetett elvek alapján az összes publikációs, biz- 


tonsági, megjelenési, hitelesítési és minden 


MEA ee TET A 








egyéb más lényeges beállítást elvégezhetünk. 
Rettentően összetett eszközt kapunk a ke- 
zünkbe, amelynek menüszerkezetében eleinte 
simán eltévedhetünk, de ez csak azt bizonyít 
ja, hogy az IAG 2007 nagyon sokat , tud". 
Szummaként és a személyes tapasztalataim 
alapján bátran elmondhatom, hogy az IAG 
2007 már egy rövid megismerkedés után is 
bizonyíthat. Aki ismeri az ISA-kiszolgálók, il 
letve például a Terminal Services Gateway, a 
TS Remote Apps, valamint a TS Web Access 
alkalmazás publikálási lehetősé- 


geit, az szorozza meg ezt egy bor- 
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zasztó nagy számmal, és akkor meg- 
kapja ennek a terméknek a hasz- 
nálhatóságát és a komplexitását. 

Slusszpoénként szeretném még 
elárulni azt is, hogy a Forefront csa- 
lád egyik elemeként készült termék- 
vonal következő példánya a Unified 
Application Gateway (UAC), amely 
csak és kizárólag 64 bites Windows 








[domtarertetsátá 
Server 2008-on fut majd. Már tesz- 
tet ... z j . 
TE] ea] teljük - a 2009-es évben érkezik 
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A Microsoft termékei, technológiái és szolgál- 
tatásai arra születtek, hogy valóra váltsák 
ügyfeleink igényeit a világ minden táján. 





Keressük azokat az informatikai szakembereket, 
akik tapasztalataikkal, és elhivatottságukkal 
segítik a Microsoft ügyfeleit informatikai 
megoldások kialakításában. 


A Microsoftnál minden lehetőség adott, hogy 
önmagad légy és megvalósítsd ötleteidet! 


és a birtokomban lévő információk 


Elismert 


Izgatott 





Nyitott technológiai pozícióink a karrier és 
tanulási lehetőségek széles skáláját nyújtják 
tapasztalt és tanulni vágyó informatikai 
szakembereknek egyaránt: 

e . Architect - Core Infrastructure 

e . Architect - Business Productivity 

. . Engagement Manager 

e . Project Manager 

e . Solution Sales Professional -— SOA 

e . IPTV Premier Field Engineer 

e . Consultant - Application Development 
e . Consultant - Infrastructure 

e . Partner Technical Consultant 
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IAG 2007 Technical Resources 
http://technet.microsoft.com/en-us/ forefront/ 
edgesecurity /bb68/299.aspx 

IAG 2007 portá 
http://www.microsoft.com/ forefront/edge- 
security tag/default.mspx 

Részletes klienstámogatási adatok: 
http://www.microsoft.com/technet/forefront/ 
edgesecurity/fag/system-regvirements.mspx 
Forefront Edge Security and Access 
Demonstration Toolkit 

http://www.microsoft.com/ forefront/edge- 
security trial.mspx 








alapján már most is valószínűnek tartom, 

hogy lényegesen kívánatosabb és egyúttal 

könnyebben elérhető lesz egy nagyobb réteg 
számára, mint jelenleg az IAG 2007. 

(Folytatjuk) 

Gál Tamás 

(v-tagak Omicrosoft.com) 

Microsoft Magyarország 


Kdgcr HÁT 


A pozíciókról bővebben karrieroldalunkon 
olvashatsz: www.microsoft.com/hunzkarrier. 
Ha felkeltette érdeklődésed a Microsoft, kérjük, 
hogy jelentkezz az allasoamicrosoft.com 
címen egy önéletrajz küldésével! 





Microsoft 


Neked lehetőség. Nekünk kihívás. 


Microsoft TechNet 
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IPVÓ — A 


CALC.EXE 





RENESZÁNSZA 


Ezt a cikket lehet, hogy nem nekem kellett volna megírnom, 


hanem valami hálózatos szakértő kollégának. 


Igy egész biztosan nem lesz olyan mély — cserébe lehet, 


hogy a szerverüzemeltető szakemberek is érteni fogják. 


ehát IPv6. Azaz IP version 6. Gondolom, senkit sem fog meg- 
T lepni, hogy most az IP version 4-et használjuk. Az 5-ös? Eltévedt 
valahol. 

Ilyenkor a , meghalt a király, éljen a király" logikával a szerző ne- 
kiáll szidni a régit, hogy utána könnyebb legyen dicsérnie az újat. A 
lehetőség most is csábító, de próbáljunk meg ellenállni neki. Nem is 
olyan rossz ez az IPv4. Gondoljunk bele: már 1990 körül elkezdték 
kongatni fölötte a vészharangot. Hol volt akkor még a www? Pocok. 
Meg FTP. Ilyesmiket pötyögtek az emberek az akkor még nem létező 
böngészők helyett a parancssorba. De már megjósolták, hogy egyszer 
el fognak fogyni az IP-címek. Aztán most, 2008-ban is csak mondo- 
gatjuk, hogy igen, tényleg el fognak fogyni az IP-címek. Valamikor. De 
akkor biztosan. 

Hogyan sikerült eddig megúsznunk a katasztrófát? CIDR. Meg 
NAT. Ők a hősök. 

A CIDR (Classless InterDomain Routing, barátainak csak cider) 
egy címkiosztási nonszenszt volt hivatott orvosolni. Ezt a nonszenszt 
összefoglalóan címosztályoknak hívták. Egészen biztos vagyok benne, 


hogy valamikor mindenki szorgalmasan biflázta, hogy aszongya: 


; Bal oldali halázalokoi Hálózatok 1osloke, Hostok 
Osztály k leíró bitek li leíró bitek k 
bitek ; f száma 
száma száma 
A 0 8 127 24 16777214 
B 10 16 16384 16 65 534 
űl 110 24 D097AIS2 8 254 
D (multicast) 1110 
E (foglalt) 1111 


Így nézett ki a classful címkiosztás. A 32 bites IP-címből A osztály 


esetén az első 8 bit jelentette a hálózat címét, a többi 24 pedig a node- 
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ot azonosította. Nyilván a matekozás adta lehetőségekből a gyakor- 
latban le kellett vonni valamennyit, emiatt maradnak el a maximális 
számok az elméleti maximálistól. (Például a B kategóriánál elméletileg 
65 536 hálózat jöhetett volna szóba, de a kötelező 10" indítás miatt 
kiestek a 00), "11, "01 lehetőségek, azaz megnegyedeltük a plafont. 
A node-ok száma meg azért csökkent kettővel, mert kiesett alul a net 
work-azonosító, felül meg a broadcastcím.) 

Nos jött egy amerikai egyetem, amelyik jókor volt jó helyen, igé- 
nyelt magának egy B kategóriás címet. Megkapta. Nehogy már síny- 
lődjenek a diákok a campusban. Jött Kovács János, megigényelte a 
169.254.0.0/16 B osztályú címtartományt. Megkapta. És így teltek: 
múltak a napok, fogytak a címek. 

Néhány későn ébredő országnak már csak C kategóriás cím ju- 
tott. Igaz, abból több is, na de milyen már, hogy egy ország 254 cí- 
menként routolgasson? Miközben az A és B kategóriás címeknél meg 
ott volt egy csomó használaton kívüli IP-cím. Egészen vad dolgok 
történtek. De azért látszott, hogy ez így nem tartható sokáig. 1993- 
ban színpadra is lépett CIDR - és rendet vágott. Két fontos dolgot 
tett lehetővé: 

a Megengedte, hogy szanaszét subneteljék a nagy hálózatokat. 
a Megengedte, hogy öszekapcsoljuk a kis hálózatokat. 

Hogyan? Elkezdtük tologatni a biteket a subnetmaszkban. Az első 
esetben jobbra, a második esetben balra. 

Nézzünk egy példát. Kaptunk két C kategóriás címtartományt: 

a 192.168.0.0/24 
x 192.168.1.0/24 

Ugyanezek binárisan: 

11000000 10101000 00000000 00000000 — IP-cím 

11111111 11111111 11111111 00000000 — Subnet-maszk 


11000000 10101000 00000001 00000000 — IP-cím 
11111111 11111111 11111111 00000000 — Subnet-maszk 


Legyünk bátrak, toljuk el egy bittel balra a subnetmaszk határát. 
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11000000 10101000 00000000 00000000 — IP-cím 
11111111 11111111 11111110 00000000 — Subnet-maszk 
11000000 10101000 00000001 00000000 — IP-cím 
11111111 11111111 11111110 00000000 — Subnet-maszk 


Látjuk, mi történt? A piros karakterek jelentik az egy hálózatba tar 
tozó node-okat. Az eltolással elértük azt, hogy a két hálózatunk im- 
már egynek számít. Úgy is jelöljük, hogy 192.168.0.0/23. 

Nézzünk egy másik példát. Kapunk egy B kategóriás címet. Illetve, 
mit is beszélek? Már nincs sehol sem B kategóriás címtartomány. 
Pontosabban van, de erről majd később. 

Ez a tartományunk: 172.18.0.0/16. Igen ám, de van 50 telephe- 
lyünk, szanaszét az országban, mindenhol 100 node-dal. Hülyeség len- 
ne ezt egy hálózatnak tekinteni, de nem rendelhetek meg 50 darab B 
kategóriás címtartományt sem. 


Nézzük, milyen pályán játszunk: 


10101100 00010010 00000000 00000000 — IP-cím 
11111111 11111111 00000000 00000000 — Subnet-maszk 


Mi: lenne, ha most jobbra csúsztatnám el a subnetmaszk határát? 


10101100 00010010 00000000 00000000 — IP-cím 
11111111 11111111 10000000 00000000 — Subnet-maszk 
10101100 00010010 10000000 00000000 — IP-cím 
11111111 11111111 10000000 00000000 — Subnet-maszk 


Rögtön két, különböző hálózatot kaptam! 
m 172.18.0.0/17 
m 172.18.128.0/17 

És még nincs vége, a subnetmaszk határát egész bátran tologatha- 
tom még jobbra, még több, még apróbb hálózatokra tagolva a címtar- 
tományomat. Nyilván ez a másik irányra is érvényes - csak akkor apró 
hálózatokból rakok össze nagyobbakat. 

Jó, és akkor mit csinált a NAT? 

Nos, elbújtatta a hálózatokat. 

A címkiosztók idejében kapcsoltak, és minden címosztályban kije- 
löltek egy-egy tartományt. Azt mondták, az ebből a tartományból jövő 
címek értelmezetlenek lesznek az interneten. Nem léteznek. Mint egy 
véletlenül kicsúszott büfi egy üzleti tárgyaláson: mindenki hallotta, 
de senki sem reagál rá. 


Ezekről van szó: 


Címtartomány Alsó határ Felső határ 

A 10.0.0.0 10.255.255-255 
B 172.16.0.0 I72731010 

Ű 192.168.0.0 IZTG0 255255 


Legyen egy vállalatunk, mondjuk, 100000 számítógéppel. Tételezzük 
fel, hogy egy darab router köt össze minket az internetszolgáltatónkkal. 
A router belső felétől már mi vagyunk a májerek, azt csinálunk, amit 
akarunk. Mit akarunk csinálni? Hát, például használjuk a 10.0.0.0/8 há- 
lózatot. Ez teljesen védett címtartomány, bárki is használja rajtunk kívül, 
a neten nem fog megjelenni. Ha jól csináljuk, akkor a miénk sem. Jó, 
jó... de akkor mi fog megjelenni? Hát az az egy IP-cím, amelyet a szolgál 
tatónk adott, és mi a router külső lábához illesztettünk. Mind a 100000 


alkalmazott azon az egy IP-címen keresztül fogja tolni az iwiw-et. 
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Server 





Src. 10.00.2:3123 
Dst. 143.23.0.4:80 
l Protocol, TCP 


Gateway 19.0.0.1 


Src: 15755. 1.104135 
DOst. 143.23.0.4:80 
Protocol: TCP 


1090.0.1 


157.55.1.10 143.23.0.4 
Port Mapping 

InternaliP  10.0.0.2 

Internal port 3123 

ExternaliP  157.55.1.10 


External port 4135 
Remote host 143.23.0.4 
Remote port 30 











Végtelen mennyiségű hálózat egymás mögött 


Részletesen ebbe most nem mennék bele, egy jó ábra száz szónál is 
szebben beszél. 

Nos, nagyjából látjuk, hogyan is állunk. Az internet köszöni szé- 
pen, működik. A NAT segítségével gyakorlatilag végtelen mennyiségű 
hálózatot tudunk egymás mögé bújtatni. 

Mi: akkor a probléma? 

Például a NAT: 
am Azért csak erőforrás-igényes. Vessünk ismét egy pillantást az ábrá- 

ra. Láthatjuk, egy kapcsolathoz a routernek el kellett raktároznia 

a port mapping értékeit. Mi van, ha több ezer kapcsolat pörög át a 

routeren percenként? Füst. Meg csökkentett felhasználói élmény. 

a Mi van akkor, ha erőforrásokat akarunk publikálni az internet fe- 
lé? Mondjuk, két darab webszervert? A routernek csak egy darab 
80-as portja lesz. A másik webszervernek már bele kell törődnie a 
nem szabályos portba, vagy trükközni kell. 

a Titkosítás. Gondoljunk csak az L2IP VPN-re. Ha a router belepisz- 
kál a csomagba, akkor hiába írtam alá odabent digitálisan, az egész 
megy a levesbe. Arról nem is beszélve, hogy egy rendesen titkosított 
csomagot nem is tud értelmezni a router. (Mondjuk, a NAT traver- 
sal - IPSEC NATT - segítségével le lehet kezelni a problémát, vi- 
szont ez erőforrásba kerül.) 

De mi a helyzet például a stream jellegű adatfolyamokkal? A mobilb 
internettel? 

Miközben persze az igények is egyre nőnek. Nehogy már ne én 
mondhassam meg a kenyérpirítónak, hogy mikorra érek haza, és 
mennyire süsse át addigra a kenyeret! A hűtőgépem pedig küldjön 
figyelmeztető e-mailt, ha kevés benne a sör. Ez mind-mind IP-címet 
kíván. Méghozzá egyedit, mert egy benatolt kenyérpirító, lássuk be, 
nem az igazi. (Lehet, hogy a router mögött már a porszívó foglalta le 
a megfelelő portot.) 

Bizony, ezek az igények az IPimechanizmus alapjait ostromolják. Itt 
már nem segít a patkó továbbpatkolása - a gyökerekhez kell hozzá- 
nyúlni. 


Ez lesz/van az IPv6. 


IPvó-alapok 

De előtte egy kis történelem. 

a 1990. Az IETF megállapítja, hogy baj van. Belevágnak a CIDR-be. 

a 1993. Az IETF kezdeményezésére beindul az IPng (new generation) 
kidolgozása. Még ebben az évben kijön az RFC1719, egyfajta irány- 
elvgyűjtemény. 


a 1995. Rengeteg felmérés, ötletelés után elméletben összeáll a kép. 


Microsoft TechNet 


met 
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Az újszülöttet IPv6-nak nevezik el. 

Ízlelgessük egy kicsit: 1995. Én 1997 körül kattantam rá a telefon- 
drótra. Emlékezzünk vissza, milyen is volt akkoriban nálunk az IPv4- 
net? Nem merem azt mondani, hogy gyerekcipőben járt... az anya- 
méhben ugyanis logisztikai problémák miatt nem szoktak tipegőt 
hordani a csöppségek. 

És akkor vágjunk végre bele. 

Alapvetően az IPv6 az IPv4 továbbfejlesztett változata. Ez minden- 
képpen jó hír, mert azt jelenti, hogy nem lesz olyan irgalmatlan hatal 
mas nagy paradigmaváltás. Mint a neve is mutatja, elsősorban az IP 
rész változik. A TCP például nem. De azért lesznek hullámzások. 

Mire is jó az IP? A címfeloldásra. Milyen címeket is oldunk fel? 
Hát, ugye, az alkalmazás azt mondja, hogy őneki az sal001.cegnev. 
hu géppel kell hetyegnie. A DNS-szervertől meg kell kérdeznie az 
sal001.cegnev.hu névhez tartozó IP-címet. A DNS-szerver visszaadja. 
(Hoppá, egy hullámzás: a DNS-nek majd ismernie kell az IPv6-címe- 
ket.) Az alkalmazás innentől a 192.168.14.24 IP-címet fogja keresni. 
Az IP.protokoll dolga lesz, hogy megtalálja az ehhez a címhez tartozó 
hálózati kártya MAC addressét. Ennyi a történet az IP részéről. Ez fog 
megváltozni. 

No még egyszer. Mire is jó az IP? A címfeloldásra. Ki segít neki eb- 
ben? Hát az ARP. 

Na, őt kinyírták. 

Maga a címfeloldás mechanizmusa az, ami gyökeresen megválto- 
zott. Meg az IP-cím szintaxisa. Meg az IP-fejléc. Meg... na, jó. Egy nap- 
ra legyen ennyi is elég. 

Kezdjük az elején, nézzük az IP-címet. Az IPv4 32 bites volt. Az IPv6 
128 bites lett. Ha szigorúan matematikusszemmel nézzük, ez azt jelen- 
ti, hogy a címtartomány mérete a negyedik hatványára emelkedett. 
Hogy ez mekkora szám? Nem kicsi. Több frappáns hasonlat is kering 
a neten, legyen ezek begyűjtése a házi feladat. 

Az IPv4-címeket oktettekre bontottuk, majd az egybájtnyi értéke- 


ket decimális formában használtuk: például 


11000000 10101000 00010111 00001100 
azaz 192. 883029 o 2 


Az IPv6-címeknél ez meglehetősen húzós lenne. Próbáljuk ki: 


11000000 10101000 00010111 00001100 11000000 10101000 00010111 00001100 
11000000 10101000 00010111 00001100 11000000 10101000 00010111 00001100 
ezaz 82. 09029 o 2 o 92 o 08029 o 2 a 2, 1A8o28 o Zo 82 108029 o 1 


Látszik, hogy ezeket a számokat ember nem fogja tudni megjegyez- 
ni. [de valamilyen tömörebb ábrázolás kell. Úgy van, látom sokan vág 
ják egyből: igen, barátunk, a hexadecimális. 

És akkor most felírok egy IPv6-címet: 

Látható, hogy az elválasztójel megváltozott, pont helyett kettős- 
pont lett. Az is látható, hogy 8 egységünk van, egységenként négy 
karakterrel. (Ahol ennél kevesebb van, oda nullákat kell eléjük ten- 
ni.) Mekkora szeletet jelent egy betű? Négy bitet, azaz egy fél bájtot. 
Naná... azért hexadecimális. 

Gyakoroljunk. Hogyan nézne ki a fenti IPv4-cím IPv6-formában? 
Így: c0a8:170a. 

A jó hír, hogy tényleg rövidebb. A rossz hír, hogy ezeket a számolga- 


tásokat soványmalac vágtában el kell sajátítanunk fejben, ha IPv6-há- 
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lózatokat akarunk üzemeltetni. Immár nem az aknakereső lesz a har- 
madik leggyakrabban használt alkalmazásunk, hanem a calc.exe. 

És persze még nincs vége. Ha az egyes blokkokban például csak nulk 
lák vannak, akkor az elhagyható. Konkrétan a fenti IPv6-cím így is ír- 
ható: fe80::fd12:2f£1:1234:abcd. Vegyük észre, hogy ahol kimaradtak a 
nullák, ott megduplázódtak a kettőspontok. Hogy mennyi maradt ki? 
Tudjuk, nyolc részletnek kell lennie, látunk ötöt - tehát háromblokk- 
nyi nullánk van. Vigyázat, egy címen belül csak egy ilyen összevonás 
lehet! Nincs olyan cím, hogy fe80::abcd::21 - tekintve, hogy ekkor 
nem tudnánk, mely részen hány üres blokk volt. 

Aztán ebből elég vad dolgok is ki tudnak sülni. Hogy mást ne 
mondjak, a localhost: ::1 

A subnetmaszk mint elv megmaradt - csak most már prefixnek 
hívják. Nagyjából ugyanúgy is használjuk: fe80:0:1234:adf:2::/6 4. 

A /64 az, ugye, jelen esetben azt jelenti, hogy a cím fele a hálózati 
azonosító, a második fele pedig a hostazonosító, egész konkrétan: 
nx hálózat: fe80:0:1234:adf 
m host: 2:0:0:0 

Eddig a gyerekmedencében pancsikoltunk. Lassan itt az ideje a mé- 
lyebb víz felé venni az irányt. 


Persze előtte még zuhanyozunk... azaz definiálgatunk. 


Címzések 

Az IPv6 alapvetően háromfajta címet ismer: 

a unicast, 

nm anycast, 

a multicast. 

Nagyon durván leegyszerűsítve: a unicast címre küldve egy csoma- 
got, csak egy node fogja megkapni azt. Multicast címre küldve egy 
csomagot, mindenki megkapja, akinek az a multicast címe. Az any- 
cast cím ugyanolyan, mint a multicast, de ha valamelyik node rácsap 
a forgalomra, akkor arra rá lesz csapva. Másnak már nem jut belőle. 

Biztos lesz olyan, akinek ez ismétlés, de nem árt az alapokat sem 
tisztázni. 

Mi is rejlik az olyan fogalmak mögött, hogy host, node, subnet, 
link? 

n Host: tulajdonképpen számítógép, akár több hálózati kártyával. 

a Node: MAC addres-szel rendelkező hálózati pont. I MAC address, 
1 node. Ha egy számítógépben két hálókártya van, akkor az két 
node. 

a Subnet: alhálózat. Az egy subneten belüli hostok router közbeikta- 
tása nélkül is tudnak egymással kommunikálni - feltéve, hogy egy 
linken vannak. 

m Link: fizikailag egy dróton lévő hostok összessége, amelyeket egy 
router szeparál el a hálózat többi részétől. Az esetek nagy részében 
ez egy subnet is, de nem kötelezően. Minden további nélkül lehet 


egy fizikai hálózaton - linken - több subnet is. 


Unicast címek 

A következő unicast címek léteznek: 

a unigue global, azaz egyedi globális cím; 

a linklocal cím, azaz csak a linken értelmezett cím; 

ma sitelocal cím, azaz csak a lokális site-on értelmezett cím; 


a uniguedocal, azaz lokálisan egyedi cím; 


KA / 
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ax speciális címek 
m transition, azaz áttérési címek. 

Egyenként. 

Egyedi globális címek. Az egyedi globális címek, mint a nevük is 
mutatja, abszolút egyediek. Az egész világegyetemben. Felépítésük 
nagyjából így néz ki: 


feg0:0:0:0:fd12:2f1:1234:abcd 


a 001: ez a fix része a címnek. 

a Global routing: ettől lesz a cím globális. Tulajdonképpen ebben a 
tartományban fognak nyüzsögni az ISP-k. 

a Subnet ID: a globális címen belüli alhálózatok. Logikusan 65 536 
lehet belőlük. 

ma Interface ID: a node egyedi azonosítója. Mivel ez egy olyan elem, 
amely a legtöbb címzési technikánál visszaköszön, érdemes el 
mélyedni a generálásában. Létezik egy kódolás, 64-bit Global 
Identifier (EUI-64) a pontos neve. Ennek van egy olyan fejezete, 
amelyik azzal foglalkozik, hogyan is lehetne egy 48 bites MAC 
(IEEE 802) addressből 64 bites egyedi azonosítót fabrikálni. Le 
fogsz esni a székről, ha elárulom, hogyan: a MAC address közepé- 
re beszúrnak 16 bitet, méghozzá ezeket: FFFF. Pontosabban, ez a 
szabvány, de az ÍPv6-ban inkább az FFFE értéket szúrják be. Még 
pontosabban, ez csak az egyik lehetséges mód interface ID generá- 
lására... de a legnépszerűbb. (Apropó, azt ugye tudtad, hogy a MAC 
address első 24 bitje a gyártó azonosító kódja, a második 24 a kár 
tyáé? Azaz az FFFE érték pont a kettő közé szúródik be.) 
Megjegyzés: a fenti címképzés az elméleti változat. A gyakorlat 

ban beszúrtak a tervezők néhány matyó csujjogást a koreográfiába: 

a MAC address gyártóspecifikus részében a konverzió során átfordí- 

tanak egy bitet. Pusztán a tömörebb számábrázolás kedvéért. A teljes 


folyamat az ábrán látható. 





IEEE Administered Manu facturer Selected 
Company ID Extension ID 


24 bits 24 bits 
mezmeza 






IEEE 802 Address: 





EUI-64 Address: 


1! 0xFF 0xFE 


11111111 11111110 XXXXXXXX XXXXXXXX XXXXXXXX 
64 bíts 


A ámképzés teljes folyamata 





IPv6 Interface 
identifier: 











Linklocal címek. A linklocal címek olyan címei egy node-nak, 
amelyek csak az adott linken érvényesek. A router ezeket a címeket 


nem fogja kiengedni. 


nd! 


Képzésük: 
11111111010]54 0 bitlInterface ID (64 bit)! 


a 1IIII11010: fix érték. 
a 54 üres bit: meglehetősen fix érték. 
a Interface ID: már ismerjük. 

Gondolom, látod te is, hogy ez az egész felírható úgy is, hogy 
FES80::/64 prefix t node azonosító. 

Site.local címek. Amikor ilyen nagy címtartományunk van, si- 
mán előfordulhat, hogy ún. köztes alhálózati rendszert iktatunk be 
a prefix és az interface ID közé. Ezeket a köztes alhálózatokat hívják 
site-nak, a site-on belülről kitörni nem képes címeket pedig site-local 
címeknek. 


Így néznek ki: 
IL111111011]subnet azonosító (54 bit) Interface ID (64 bit)] 


Unigue local address. A helyzet az, hogy a site-local címek miatt 
nem lehetünk 100 százalékig biztosak abban, hogy a linklocal cí- 
meink abszolút egyediek a linken. Emiatt vezették be a uniguelocal 
címeket. 

Speciális címek. Például a localhost: ::1/128. 

Transition címek. Átállítani az internetet az IPv6-ra... igen nagy fa- 
lat lesz. Nem is fog menni egyik napról a másikra. A békés átmenet ér- 
dekében szükségünk lesz egy csomó kétéltű címre. Itt csak felsorolom 
ezeket, nagy a net, akit mélyebben érdekel a téma, utána tud nézni: 
n [Pv4-compatible address; 

a [Pv4-mapped address; 
a 6to4 address; 
ISATAP address; 

a Teredo address. 


MNulticast címek 
Általában így néznek ki: 


MLI111]Flags (4 bit) Scope (4 bit) [Group ID (112 bit)! 


Ebbe most nem mennék bele túl részletesen, a flagnek is és a scope- 

nak is meglehetősen sok variánsa van. Inkább csak felsorolom azokat, 

amelyekkel sűrűn fogunk találkozni a hétköznapokban. Az összes elő- 
re definiált multicast cím egyébként az FFOI:: - FFOE:: címtartomány- 
ban található, ide egyszerű halandó nem is definiálhat saját címeket. 

a FFOI::1 - interfacelocal scope alknodes multicast address, azaz 
minden-node multicast cím, hoston belül. 

a FFO2::1 - link-local scope alktnodes multicast address, azaz minden- 
node multicast cím, linken belül. (Vegyük észre, hogy ez tulajdon- 
képpen a broadcast! Nincs is külön, megszűnt. Ez a multicast cím 
van helyette.) 

m FFOI::2 - interfacelocal scope allrouters multicast address, azaz 
mindenrouter multicast cím a hoston belül. 

n FFO2::2 - linklocal scope allkrouters multicast address, azaz min- 
denrouter multicast cím a linken belül. 

an  FFO5::2 - sitedocal scope allrouters multicast address, azaz minden 
router multicast cím a site-on belül. 

Rengeteg egyéb előre definiált multicast cím létezik - például az ösz- 


szes DHCPv6 szerver, meg egyéb ínyencségek. Tessék utána olvasni! 
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Fontos megemlíteni még egy speciális multicast címet is, ezt úgy DGP Enadled s 
hívják, hogy solicited-node address. De erről a következő részben fo- Autoconfiguration Enabled : Yes 
Link-local IPv6 Address — : fe80::5efe:192.168.1.101510(Preferred) 


gok részletesebben is beszélni. 
Default Gateway 


Gondolom, elég sok ez így első körben. Ismétlésképpen nézzük vé- DNS SET ató B4.2.44.1 
gig, milyen címekre is kell hallgatnia egy mezei hálókártyának: 84.2.46.1 
n linklocal cím; NetBIOS over Tcpip : Disabled 


nm uni lobal; 
nigue g Illetve a route tábla: 
a unigue local; 


a loopback; HENNNENSNTNSN SÉT T TT 


a minden-node hoston belül; Interface List 
ie ássák jéé 8 — 00 e 8c ab 2f 88 Realtek RTL8168B/8111B Family PCI-E 
EEEBEMEKSES ÉRE NS SES EE ÉÉKSZÁR AKK Gigabit Ethernet NIC (NDIS 6.0) 
a solicited-node; 1 Software Loopback Interface 1 
a egyedi multicast címek. 9 — 020054 55 4e 01 Teredo Tunneling Pseudo-Interface 
Durva egy kicsit. Ez ugyanis mind egy-egy IP-cím, amely a kártyá- el [NNAK kését AE STONE 
Most, hogy már van némi fogalmunk az IPv6-címzésről, érdemes 
lehet végignézni annak a gépnek az IP-konfigurációját, amelyen ezt a IPv4 Route Table 
Active Routes: 
Windows IP Configuration Network Destination  Netmask Gateway Interface Metric 
0.0.0.0 00.040 192.168.1.1  192.168.1.101 20 
Host Name :hg 127.0.0.0 255.0.0.0 On-link NZZRONONA 306 
Primary Dns Suffix: 127.0.0.1 255.255.255.255 — 0On-link 127-0.051 306 
Node lype : Hybrid 127.255.255.255 255.255.255.255 — 0n-link TAZSÓÁDSI 306 
IP Routing Enabled — : No 192. 16810 255.255.255.0 — 0n-link 192168. 1.101" "276 
WINS Proxy Enabled — : No 192.168.1.101 255.255.255.255 — On-link 102168. 1 10000276 
192.168.1.255 255.255.255.255 — 0n-link 192.168.1.101 276 
Ethernet adapter Local Area Connection: 224.0.0.0 240.0.0.0 0n-Tink 127001 306 
i j 224.0.0.0 240.0.0.0 0n-link 192.168.1.101 "276 
Connection-specific DNS Suffix  . : 255.255.255.255 755 Z5SÉZHB, Z55VN (On T1nk JÖZE0 DS 306 


Description Realtek RTL8168B/8111B Family PCI-E 
Gigabit Ethernet NIC (NDIS 6.0) 
: 00-1E-8C-AB-2F-88 


259 .LIDLIDL9] 229.25904250-.499  00-Mmk NYZETSSÉRL ETO A ZT6 


Physical Address Persistent Routes: 


DHCP Enabled : Yes Me 
Autoconfiguration Enabled : Yes 
Link-local IPv6 Address : fe80::c5cc:1c5c:8384:454628(Preferred) TEKNO RÉTEN 
IPv4 Address SESZET OS SET P neger reg SS [o 0 UédUWLEce oo s FF CSE Es 
Subnet Mask 1 255.255.055. ÜÉ SET NE [ER E. 
Lease Obtained : 2008. június 3. 19:14:09 kt 
Lease Expires : 2008. június 4. 19:14:08 SOS ans 
Default Gateway . 192.168.1.1 Ni Metric Network Destination me 
DHCP Server : 192.168.1.1 Mg dalae 
DHCPvő AID : 201334412 e On-Tink 
DNS Servers : 84.2.44.1 9 18 —  2001::/32 On-Tink 
BAR AG 1 9 266 2001:0:d5c7 :a2ca: 3c2f :2bc6:3157:fe9a/128 —— 0n-link 
NetBIOS over Tcpip Enabled 8 276 — fe80::/64 On-link 
9 266 feg0 : : /64 On-link 
Tunnel adapter Local Area Connection" 6: 10 281 feg0: :befe:192.168.1.101/128 On-Tink 
9 266 feg0: : 3c2f:2bc6:3f57:fe9a/128 On-link 
Connection-specific DNS Suffix 8 276 feg0: : cscc: 1c5c:8384:4546/128 On-link 
Description : Teredo Tunneling Pseudo-Interface 1 306 FT0055/8 On-Tink 
Physical Address : 02-00-54-55-4E-01 a 266 100 :/8 On-Tink 
DHCP Enabled : No 8 276 ff00: : /8 On-link 
Autoconfiguration Enabled : Ves --------------bbbbt----- 
IPv6 Address : 2001:0:d5cZ:aZca: 3c2f:2bc6:3f57:fe9a Persistent Routes: 
(Preferred) None 
iMLAS OS kllk be 1 TESZEK EBL E AGE gA KKE GET Csemegézzünk! Vajon mi lehet az IPv6-címem? Vigyázat, beugrató 
NetBIOS over Tcpip : Disabled kérdés, ugye, elég sok lehet. De jelen esetben csak link-local címeket 


látunk, az egyik például így néz ki: fe80::cScc:1cSc:3384:4546908. 


Tunnel adapter Local Area Connection? 7: Egis 1 kád : j fzasézt ő ; ejő 
ü Ránézésre is több baj van a címmel. Először is, mi az a 908 a végén? 


Connection-specific DNS Suffix  . : Aztán az interface ID egyáltalán nem úgy néz ki, mintha a MAC ad- 
Description : isatap. (47CE5CAA-223F-4CD4-9A17-D91D7DDC2066) dressből képezték volna betoldással. Arulás? Nos, a 968 formulára 
Physical Address : 00-00-00-00-00-00-00-E0 


egyszerű a válasz: egyszerű cím esetén ez az interface azonosító száma, 


MÁJUS-JÚNIUS Li 
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úgynevezett zónaazonosító. (A route-táblánál látható, hogy konkré- 
tan egy Realtek hálókártyáról van szó.) 

Jó, akkor mi van az Interface ID-val? Az, hogy az EUL64 nem köte- 
lező. A Windows Server 2008, illetve a Vista alaphelyzetben például 
véletlenszerűen generált interface ID-t használ. Erről a következő pa- 


rancs segítségével tudjuk lebeszélni: 


netsh interface ipv6 set global randomizeidentifiers-disabled 


Miután kiadtam ezt a parancsot, és megújítottam az IP-címemet, a 


következőt kaptam: 


Link-local IPv6 Address: fe80::21e:8cff:feab:21888 


Ugye, mindjárt más?! Ez már EUI-64. A matyó csujjogatással. 

Miért is nincs globálisan vagy lokálisan egyedi (global/local uni- 
gue) címem? Mert a routerem azt mondta, hogy nekem olyanom 
nincs. Pontosabban, nem mondta, hogy van. 

Aztán nagyon elszaladtunk amellett, hogy nekem nem is egy link- 
local IPcímem van. Mi is a többi? Nos, transition címek. Azok, ame- 
lyeket csak úgy megemlítettünk korábban. Most sem kapnak nagy 
szerepet... de azért vegyünk észre valamit: mindkettő, a Ieredo és az 
Isatap is Tunnel Adapter Local Area Connection néven fut. Iunnel... 
valami belecsövezve valamibe. Mi van most? IPv4. Mi lesz majd? IPv6. 
Nyilván logikus, hogy ezeket a címeket használva tulajdonképpen az 
IPv6-ot csatornázzuk bele az IPv4-be. Végül egy kérdés: ha teszem azt 
a Magyar Telecom globális azonosítója 1100 0000 0000 0000 0000 
0000 0000 0000 0000 0000 0000 I, és én ezen belül a 0000 0000 


Flow Label 


fs Source Address ús 


40 Byte 


a Destination Address Za 











IPv6-csomag fejlécének felépítése 


négyszeresükre nőttek, a fejléc csak a duplája lett. Racionalizálás, ké- 
rem szépen, racionalizálás. 


(Gondolom, nem kell külön kihangsúlyoznom, hogy az új csomag- 


struktúrához új ICP/IP stack is kell.) 


A címfeloldás — ARP nélkül (Neighbour Discovery, ND) 


Ha már rajtunk a búvárfelszerelés, ne fecséreljük az időt. Nézzük meg, 
hogyan is történik majd IP-szinten a névfeloldás? 


De előtte lássuk azt, hogyan is történt régen? 





TN DS byte 


ragttjjtsée tát e det" 


te 1 ég 
Frag. Offs et 


H. Checksum 








Ver. Protocol version 
Source Address IHL: IP Header Length 
Destination Address DS byte: Differentiated Services byte 
; Options TTL: Time To Live 
l 
BES z  Bai Options 
Options 9 j Padding 


Az A node kapcsolatba akart lépni egy konk- 
rét IP-című géppel. (Ezt a címet már megmond- 
ta neki a DNS.) Fogta, és szétküldött egy ARP 
broadcastot, benne a saját IP-címe, IP(A), saját 
MAC-címe, MACK(A) és a keresett IP-cím, IP(B). 
A broadcastot minden node vette a linken, felol 
vasták és megnézték, vajon őket keresik-e. Aztán 
aki birtokolta az IP(B) címet, az visszaküldte a 
MAC-címét, MAC(B) - és a sóvárgó MAC-ci- 








IPv4-csomag fejlécének felépítése 


0000 0011 subnetben vagyok, akkor mi lesz a világegyetemben egyedi 
azonosítóm? Lapátoljuk össze: 001, mert ez abszolút fix. Ehhez hozzá- 
csapjuk az ISP globális azonosítóját és a subnetazonosítót. Ez lesz a 
prefix, ehhez jön majd az interface ID, amelyet a linklocal címből tu- 
dunk kibányászni. Jelen esetben ez c5Scc:1c5c:8384:4546. Innen már 
csak matekozás: 3800::1:3:cScc:1c5c:8384:4546/64. Long live calc. 
exe. (Hint: fel kell írni bitsorozatként, bájtonként csoportosítani, át 
váltani, két bájt egy blokk.) 


IP-fejlécek 
Ezen a részen gyorsan át fogunk rohanni - ugyanis az egyes mezők 
szerepeinek kifejtése bőven meghaladja e cikk kereteit. Minden külö- 
nösebb kommentár nélkül egymás mellé teszem az IPv4- és az IPv6- 
csomag fejléceinek a szerkezetét: 

Habár azt mondtam, nem fogom kommentálni a képeket, azért 


egy dologra felhívnám a figyelmet: annak ellenére, hogy az IP-címek a 


1) 


mek vonzalma szárba szökkent. 

Ugye, nem kell mondanom, mi az eljárás hát 
ránya? Az, hogy a broadcastcsomaggal mindegyik node operációs 
rendszerének foglalkoznia kellett. 

Az IPv6-ban újítottak. Bár eljátszhatták volna mindezt a minden- 
node linklocal címre küldött üzenettel, de akkor ugyanott lennénk, 
mint az ARP broadcasttal. 

Ehelyett egy speciális multicast címre megy ki az érdeklődő üzenet. 
Ezt a speciális címet hívják úgy, hogy solicited-node cím. A követke- 
zőképpen képződik: 


IFFO2: : 1:FFOO:0 (104 bit) ] az interface ID jobb szélső 24 bitjel 


A megértés kulcsa a jobb szélső mező. Kinek is az interface ID-ja? 
Nyilván nem a feladóé. Annak nem lenne semmi értelme. Iermészete- 
sen a keresett IP-címből képződik a solicited-node cím. 

Az érdeklődő - A - node tehát legyártja ezt a solicited-node címet 
és elküldi neki a saját IP-címét, IP(A), saját MAC-címét, MAC(A) és 
persze a keresett IP-címet, IP(B). Mely node-ok fogják felkapni ezt a 
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kérést? Akiknek a - saját maguknak már korábban legyártott solicit 
ed-node - címük megegyezik a feladó által megadott solicited-node 
multicast címmel. Egész konkrétan: az a pár node fogja felkapni, ahol 
az interface ID jobb szélső 24 bitje megegyezik. A többi node békésen 
kérődzik tovább. Tiszta haszon az ARP-hez képest. 

Egy újabb gondolkodós kérdés: vajon mi is lesz az én solicited-node 
címem? 

Az első 104 bit, az ugye adott. A mara- 
dék 24 bit pedig kiszámolható az Interface 
ID-ból. 


Merre is vagy, calc.exe? 


47 Wireless Network Connection Properties "GNI 
Networking . Sharing 


Connect using: 


A). Intel(R) PRO/ Wireless 3945ABG Network Connection 


slael] x 


közni fog másik node címeivel? Bizony, igen. Ekkor jön a jó öreg ND. 
Megszólitjuk a solicited-node címen azt az IP-címet, amelyet magunk- 
nak kívánunk lefoglalni. Ha nem jön válasz, nyertünk. Miénk a cím. 

(Ki kell rá térnem, hogy a Windows-implementációnál ez is másképp 
van egy kicsit. Arról már írtam, hogy az Interface ID nem EUI-64 mó- 
don generálódik, hanem véletlenszerűen. Arról viszont nem, hogy a ter- 
vezők úgy saccolták, nagyon kicsi az esélye an- 
nak, hogy a véletlen azonosítók között egyfor- 
mák legyenek: ezért elhagyták az ellenőrzést.) 

Mi van, ha megváltozik a MAC-címünk? 
Úgy csinálunk, mintha ND kérdéseket kap- 





Tessék, a cím: ff02:1::ff00:0084:4546. 
Most az egyszer nem segítek. 

Elképzelhető, hogy valakiben felmerül a 
kérdés: mire is jó ez az egész cécó? Hiszen az 
interface ID a MAC addressből képződik... 
egyszerűen számoljunk belőle vissza, és már 
miénk is a MAC. 


Az ötlet jó... de sajnos ez csak ajánlás. Az 


Description 


interface ID sokféleképpen keletkezhet, sem- 


mi garancia sincs rá, hogy pont az EUL64 ill 


volt a keletkezésének alapja. 





This connection uses the following items: 


os Client for Microsoft Networks 
[00S Packet Scheduler 
A File and Printer Sharing for Microsoft Networks 
Intemet Protocol Version 6 (TCP/IPv6) 
4 Intemet Protocol Version 4 (TCP/lPv4) 
24 Link-Layer Topology Discovery Mapper I/0 Driver 
4 Link-Layer Topology Discovery Responder 


Uninstall 


TCPAIP version 6. The latest version of the intemet protocol 
that provides communication across diverse interconnected 


tunk volna, elárasztjuk a linket válaszokkal. 
Mi van, ha két hálókártyával is kapaszko- 
dunk egy linken? Hol ez, hol az fog válaszol 
ni az ND kérdésekre - terheléselosztás. 
Nézzük a stateful változatot. Nos, a 
DHCPv6 megint egy olyan terület, amellyel 
nem szándékozom túl sokat foglalkozni: nem 
fér már bele a cikkbe. Nyilván lesznek új 
kunsztjai. Például rá tud szólni az ügyfelekre, 
hogyváltozás történt a központi konfiguráció- 


ban, legyenek kedvesek, indítsanak el egy 








Autokonfiguráció 





új címigénylési folyamatot. Aztán a szerver 


képes lesz visszavonni is a kiadott címeket. 





Ez megint egy szép téma. Kezdjük megint az- 
zal, hogy milyen lehetőségünk volt autokonfi- 
gurációra IPv4 alatt? Igen, a DHCP. 

Az IPv6 alatt tágabb lett a horizontunk: 

a stateless autoconfiguration; 
a stateful autoconfiguration (DHCPvo); 
a kombinált bérlet. 

Vizsgáljuk meg először a stateless változatot. Messziről fogunk el 
indulni. 

Van egy hostunk, egy hálózati kártyával. Feldugjuk egy IPv6-háló- 
zatra. DHCPv6 nincs. Router van. 

A router meghatározott időnként küld egy üzenetet a mindennode 
link címre. Az üzenet sok mindent tartalmaz, többek között: 

u a router MAC-címét; 

a a linken élő prefixeket; 

a a linken érvényes MT U-t; 

a a linken érvényes maximális hop számot; 
a van-e DHCP a linken? 

És még egy csomó mindent, amelyek jelentőségét nem tudtam fel 
fogni. De már ezek is izgalmasak. Központilag szabályozható MTU? 
Hmm... finom. A link összes prefixe? Álljunk csak meg! Ha adottak a 
prefixek, a hálókártya meg ismeri a saját MAC-címét, ismeri az EUL 
64 módszert, simán le tudja gyártani magának a link összes prefixére 
a link-local címét! Mit ad még meg a prefixlista? Hát például azt, hogy 
mely prefixek vannak a linken - és melyek azok, amelyekhez át kell 
harcolniuk a csomagoknak magukat a routeren. 

Szóval belép az új állomás a linkre. Olyan korban élünk, hogy tü- 
relmetlenek vagyunk: nem várjuk meg, hogy a router körbeküldje az 
üzenetét, belerúgunk: router, küldj üzenetet! És az küld. Ez alapján a 


node összerakja magának a linklocal címeit. Elképzelhető, hogy üt 


MÁJUS-JÚNIUS 


Az IPvó alapból fent van, és eltávolíthatatlan Vistán 


Zárszó 
Tény, hogy az egyszerű mezei rendszergazda már évek óta ignorálja az 
IPv6-témát. Iény, hogy ez eddig sikeres taktika volt, mert soha nem 
tört még be igazán a technológia a Windows-világba. Remekül meg 
tudtunk élni nélküle. 

Ennek a világnak lassan vége. Ma már minden valamirevaló operá- 
ciós rendszer képes támogatni az IPv6-ot. A technológia sunyiban ter- 
jed. Nagyjából azzal a sebességgel, ahogyan bátor rendszergazdák ba- 
rátkoznak a számrendszerek közötti átváltogatásokkal. Igény van rá, 
tökéletesen együtt tud működni az IPv4-világgal, fokozatosan lehet rá 
áttérni, ahogy gyarapodnak a Windows Server 2008, illetve Windows 
Vista operációs rendszerek a vadonban. De már az XP is beépítetten 
támogatja, igaz, külön kell telepíteni (ipvó install). Windows Server 
2003 alá szintén telepíthető. Windows 2000-hez, illetve NI-hez letölt 
hető add-onként. Windows 95/98/Me számára a Irumpet gyárt ÍPvó 
winsock implementációt. 


Tényleg csak elhatározás kérdése, mikor kezdünk el vele komolyab- 


ban foglalkozni. 
No meg fogékonyság az újra. 
Petrényi József 
MCSE--M, MCITP, MVP 
(petrenyi.jozsef(osao.hu) 
SA0-Synergon 





A cikkhez rengeteg forrást használtam. A linkgyőjtemény a http://www.microsoft. 
ny/technet blogon lesz elérhető. 
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SOL SERVER 2008: 
ADATTÁRHAÁZ- 


JJDONSÁGOK 


Az SOL Server 2008-at erőteljesen továbbfeilesztették abba 
az irányba, hogy hatalmas mennyiségű adatokkal operáló 





adattárházakat tölthessünk fel és kezelhessünk a segítségével. 
Ezeket tekintjük át cikkünkben. 


z adattárházat sokan az OLAP-pal társítják, pedig ez sima relációs adatbázis-fogalom. ! (CDC) nevű, SOL Server 2008-ban megje- 

Az adattárház olyan speciálisan megtervezett relációs adathalmaz, amelyből könnyen ! lenő technológiával, vagy használhatjuk az 

és gyorsan lehet adatokat lekérdezni elemzés céljára. Sokszor OLAP-kockák bemenete- ! előző részben megismert MERGE utasítást is 

ként is szolgál, de például jelentések bemeneteként is kiválóan használható. a különbség képzésére. A CDC előnye, hogy 

Egy tranzakciós adatbázist általában erősen normalizálnak, hogy az adatokat minél kevésbé ! kis költséggel, a tranzakciós naplót olvasva 

redundáns módon tárolják. Emiatt sok, kevés oszlopot tartalmazó tábla keletkezik. Ez általá- ! normál üzemi időszakban gyűjtögethetjük 

ban ideális adatok beszúrására, módosítására és törlésére, azaz tranzakcionális igénybevételre, ! a tranzakciók lenyomatait, így mind a válto- 

de lekérdezéskor általában elég sok joinon keresztül tudjuk csak összerakni a szétszórt infor- ! záskövetés, mind az adatáttöltés nagyon kis 
mációdarabkákat, azaz lekérdezésre nem optimálisak az OLIP-adatbázis-szerkezetek. költséggel valósítható meg. 


Az adattárházak ezzel szemben tipikusan csillagsémás fel 





építésűek. Ez azt jelenti, hogy van egy hatalmas ténytábla 








































































DimReseller 
(Fact...), amely a tranzakciók lenyomatát tárolja tömören, f Resellerkey El 
GeographyKkey 1] 
és ehhez a táblához kapcsolódik sok dimenziótábla (Dim...), Resellerálternatekey BégéístsZtesétekek 
Phone Ha kkászátásüszszál. 4 Is 
amely az adatokat értelmezi. Például a ténytáblában csak any- öneszaat OrderDatekey Mászettak ág z 
. ResellerName DueDateKey g Promo s ey 
nyi van egy megrendelésről, hogy a 3-as vevő 20080203-kor LEK EZEE ShipDatekey Promotionálternatekey I 
ResellerKkey EnglishPromotionName 
(integerként tárolva!) vásárolt a 4$4-es termékből 5 darabot a EGG záei — Snanichoromationtame I 
éz ; ;, 33 fi 4. DimSalesT it PromotionKkey 
34-es akciós kóddal beárazva. Ezeket az értékeket oldják fel Te ezleákseteg esüldll EZEKET 
.. . , . pe, . ez, , SalesTerritoryAlternat... SalesTerritoryKkey a Ba Ctt al 
üzletileg értelmes információkra a dimenziótáblák. öl det tásei § Salesorderttunber jee SZE 
A ténytábla igen nagy tud lenni, akár milliárdsoros is (107 FALENET TEÁS HE lala tsztegegétg 
: : o. : SalesTerritoryGroup KEZE E tet WeightUnitMeasureCode 
sor). A dimenziótáblák tipikusan sokkal kisebbek: pár ezer, Orderouantity (al HEREGEKES EEG 
, vá; ; ELS ] EnglishProductName 5] 
de maximum pár millió sorosak. Ezeknek a méreteknek és kapsz 5 Extendedamount 
! UnitPriceDiscountPct 
arányoknak nagy szerepük lesz, amikor a szervernek tényleg TS KÉBÉEEEETESHA TAR 7 Dizcourtásount Kál 
a ui véső : z ; j j EEEN EPEN ProductStandardCost 1? Employeekey Al 
össze kell joinolnia a táblákat egy lekérdezésben. ERESOZMENÉSÉ ÉSE TotalProductcost e eezszügeay jő 
SpanishDayNameofWeek Eőjezhansűk ] 1 GAZTETT 
Az adattárházakat az OLIP-adatokból tápláljuk, sokszor ]  FrenchDayliameofieek CEZ MI ESSSSSES ZENE 
DayNumberofMonth a j ParentEmployeeNation. . . s] 
. is . . .. , 6 i Frei t 
inkrementálisan, csak, mondjuk, az aznap történt tranzakció- 2] pnyamberotvesr [IV ss 3 








CarrierTrackingNumber 





kat átlapátolva. Az adott időszak változásait azonosíthatjuk 
a többek között erre a célra tervezett Change Data Capture 1. ábra. Adattárház: csillagséma (részlet) 
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A már adattárházba betöltött adatok elem- 
zése során nagyon nagy IO-költségekkel kell 
számolni, hisz óriási méretű adatokról van 
szó. Az IO-költséget csökkenthetjük az adat 
lapok tömörített tárolásával, némi procesz- 
szorteljesítmény árán. A backup idejét és 
helyszükségletét a mentés tömörítése csök 
kenti. 

A GROUPING SETS segítségével több- 
féle szempont szerint, hatékonyan, egy me- 
netben tudunk aggregátumokat számolni, 
ami például riportok bemeneteként nagyon 
kényelmesen bevethető. 

Ha kevésbé szabályos adatokból kell tárhá- 
zat építenünk, akkor az adatok előzetes elem- 
zésére, profilozására a termék részét képező 
SOL Server Integration Services új szolgálta- 
tásait is bevethetjük, amely aztán a betöltést 
is az iparban páratlan sebességgel képes vég- 
rehajtani (per pillanat a leggyorsabb ETL- 
eszköz az adatbázispiacon). 

Az új, sokszálú partíciófeldolgozás gyor- 
sabb lekérdezéseket tesz lehetővé sokprocesz- 
szoros gépeken. Az indexelt nézeteket is to- 
vábbfejlesztették, így ha particionált táblán 
hozzuk azt létre, a partíciót mozgathatjuk, 
darabolhatjuk anélkül, hogy az indexelt né- 
zetet el kellene dobni. Mivel az indexelt 
nézet általában előaggregált adatokat tárol, 
azaz lassú létrehozni, ez nagy teljesítmény- 
nyereséget eredményezhet. 

Az adattárház csillagsémás szerkezetéből 
való lekérdezéseket pedig a Bitmap Filter tud- 
ja jelentősen felgyorsítani. Ezeket az újdonsá- 
gokat elemzem részletesen a következőkben. 

Előtte azonban még egy megjegyzés. Bár 
adattárházi funkcióként azonosítottam eze- 
ket az új szolgáltatásokat, valójában nagyon 
sok egyéb adatbázis alapú alkalmazás képes 
ezekből előnyt kovácsolni. Hisz a Bitmap 
Filter bármely nagy táblás joinban tud gyor- 
sítani, vagy a tömörítés sok, javarészt olva- 
sott, kevésbé módosított adatbázistábla [O- 
költségét tudja csökkenteni, nem csak egy 


adattárházét. 


Minimálisan naplózott beszúrások 

Korábbi SOL Serverváltozatokból már is- 
mert, hogy a minimálisan naplózott vagy 
más néven bulk műveletek nagyon gyorsak, 
mert a tranzakciós logba nem kerül bele pél 
dául minden egyes beszúrt sor egy bulk in- 
sertnél, hanem csak azok a lapok (8k) vagy 
extentek (64k) jelölődnek, amelyek módosul 


tak. Azaz sokkal kevesebb adat kerül a log- 

ba, több tucatszor gyorsabb lehet a művelet. 

Nemcsak a bulk insert minimálisan logolt, 

hanem a truncate table, select into tábla, 

writetext, updatetext, sőt bizonyos index 
műveletek is. 

Ez eddig is így volt. 2008-ban azonban 
már bizonyos esetekben az insertselect is mi- 
nimálisan naplózott! Ez nagy szám ám, mert 
sokan úgy töltenek be adatokat, hogy először 
nyersen behúzzák azokat egy átmeneti táblá- 
ba, aztán elemezgetik, javítgatják, tisztítgat 
ják, majd áttöltik a végleges táblába. A nyers 
betöltés mehetett már eddig is gyorsan bulk 
inserttel (akár .NEIből az SglBulkCopy 
osztállyal), vagy SOL Server Integration 
Services-zel, de a két tábla közötti adatátvi 
tel eddig teljesen naplózott, ergo, lassú volt. 
Eddig. Most már megy gyors módon is az in- 
sertselect, a következő feltételekkel. 

: Értelemszerűen csak simple és bulk logged 
recovery modell esetén működik, a full re- 
covery modell minden bulk műveletet tel- 
jesen naplózottá alakít (ez a célja). 

z With (tablock) hintre van szükség a céltáb- 
lánál, 

a Ha a táblán nincs index (heap), az adatok 
minimálisan naplózott módon kerülnek 
be a táblába. 

: Ha a táblán nincs clustered index (heap), 
de van rajta legalább egy noncusered in- 
dex, akkor az adatok minimálisan logol 
tan kerülnek a táblába, az indexek módo- 
sítása csak akkor lesz minimálisan logolt, 
ha a tábla üres volt. Ha nem, akkor az 
indexek teljesen logolt módon rögzülnek 
(mint eddig), de az adatok továbbra is mi- 
nimálisan naplózott módon. 

a Ez a feltöltöttségről szóló kitétel azért fon- 
tos, mert ha egy üres táblába nem egyszer- 
re, hanem több darabban töltünk be ada- 
tokat insertselecttel, akkor csak az első 
insert lesz minden szempontból minimáli- 
san naplózott. 

a Ha a táblán clustered index is van, csak 
üres tábla esetén lesz a betöltés minimáli- 
san naplózott. 

Nézzük, hogyan lehet meggyőződni róla, 
hogy az insertselect tényleg minimálisan 
naplózott lett-e! 

Készítsük elő a teszttáblákat! A forrástáb- 
lában jó hosszú sorokat készítünk elő, így jól 
látható lesz a kétféleképpen naplózott műve- 


let közötti különbség. 





create table Celtabla 
( 

id int, 

adat nvarchar(1000) 
) 
g0 
create table Forrastabla 
( 

id int, 

adat nvarchar(1000) 
) 
g0 


set nocount on 


declare (Oi int — 1 

while (oi — 1001) 

begin 
insert into Forrastabla 
values (Oi, replicate("ar, 1000)) 
Sa (DI r— 1 

end 


Jöhet az insertselect, először with (tab- 


lock) hint nélkül: 


begin tran --hogy ne truncate-olódjon a log mielőtt megnéznénk 


insert into Celtabla --with (tablock) 
select " from Forrastabla 


select top 100 [dog record length] Hossz, 
AllocUnitName Célobjektum, 

Context Környezet 

from fn. dblog(null, null) 

where allocunitname — dbo.Celtabla" 
order by [Current LSNI desc 


rollback 


A tranzakciós napló tartalmát az fn dblog 


függvénnyel kérdeztük le: 


Hossz Célobjektum Környezet 


2108 dbo.Celtabla LCX. HEAP 
2108 dbo.Celtabla LK. HEAP 
2108 dbo.Celtabla LK. HEAP 


Látható, hogy a dbo.Celtabla objektum- 


ba történik beszúrás, ami heapen tárolt, azaz 
olyan tábla, amelyen nincs clustered index. 
A művelet során 2108 bájt íródik a naplóba, 
minden egyes sorhoz. 


Ha a fenti kódban visszaállítjuk a meg- 


jegyzésbe tett with (tablock) hintet, akkor a 


következő lesz a log képe: 


Hossz Célobjektum Környezet 


72 dbo.Celtabla LCX GAM 


45 


72  dbo.Celtabla LCX. TAM 


92. dbo.Celtabla LO( PFS 
92. dbo.Celtabla LO( PFS 


A hossz oszlop az érdekes, bár a sor 2 ki 
lobájtos, mégis csak 72-92 bájt kerül a nap- 
lóba, mert minimális módon történt az in- 
sert. A három betűszó egyébként a Global 
Allocation Map, Index Allocation Map és 
Page Free Space rövidítése, ezek az adatok 
tárolását nyilvántartó speciális lapok. Vagyis 
az adatokat egyáltalán nem naplózzák, csak 
az azok által érintett foglalási egységeket. 

Azaz látható, az SOL Server 2008-ban ki 
bővült a minimálisan naplózott műveletek 
listája az insertselecttel, amely nagyon gyors 


adatbetöltést, -áttöltést tesz lehetővé. 


Csillag-Join optimalizálása 

Bitmap Filterrel 

Csillagjoinról beszélünk, amikor egy táblá- 
hoz sok másik táblát kapcsolunk hozzá. Mint 
láthattuk, adattárházakban pont ilyen a sé- 
ma, amikor egy hatalmas ténytáblához sok 
kisebb dimenziótábla tartozik. 

Az AdventureWorksDW . példaadatbázis 
egy ilyen tárházi minta. Ezek az adattárházi 
táblák elég speciálisan vannak tervezve, nem- 
csak a csillagséma szerkezet miatt. Például a 
FactResellerSales táblában a dátumok nem 
datetime-ként, hanem intként vannak tárol 
va. 20010701, ez egy egész szám, amit dátum- 
ként értelmezünk. Azért van ez a furcsa fel 
állás, mert integereket nagyon gyorsan lehet 
összehasonlítani, ami a JOIN szempontjából 
fontos. Emellett ráadásul 8 bájt helyett csak 
4 bájtot igényel a tárolása. 

Amikor ezeket a nagy táblákat joinoljuk, 
akkor általában szóba se jöhet a loop join a 
világ legjobb indexei mellett sem, mert száz- 
milliószor nekifutni egy táblának még in- 
dex mellett is nagyon költséges. Ilyen nagy 
tábláknál merge vagy hash join jöhet számí- 
tásba. A merge csak a kulcsok azonos ren- 
dezettsége, azaz általában akkor működik, 
ha mindkét tábla joinolt oszlopán clustered 
index van. Ez ritkán jön össze mindkét ol 
dalnál, ezért elég ritkán látni merge joint 
nagy táblák esetén. Kis tábláknál egyébként 
még arra is hajlandó a szerver, hogy a kisebb 
táblát lerendezi úgy, mint a nagyot, aztán 
merge-öl. De ezt csak pár százezer soros táb- 
lákig vállalja be, és csak akkor, ha jó sok me- 


mória van a gépben. 


Azaz, a legtöbb esetben az adattárházak- 
ban hash joinokat fogunk látni. A merge és 
a hash join is azért jobb a ciklusosnál nagy 
táblák esetén, mert mindkettő csak maxi 
mum egyszer járja be a táblákat. Igaz, hogy 
akkor sokszor az egészet, de legalább nem 
esik neki sok milliószor, mint a loop join. 

A hash join úgy működik, hogy a szerver 
a kisebb táblát a joinolandó oszlop mentén 
lehasheli, ez lesz a build input. Adattárház 
esetén az adott dimenziótábla. Épít egy hasb- 
táblát a kulcs alapján. Aki valamely progra- 
mozási frameworkből ismeri a hashtáblát, 
az tudja, hogy ez egy olyan memóriastruk- 
túra, ami nagyon gyors keresést tesz lehető- 
vé a hashkulcs alapján. A kiinduló értékek 
hashei között lesz ütközés, például az 123 és 
a 3455 is lehet, hogy ugyanarra a hashérték- 
re, mondjuk, 12-re képeződik le. Az ütköző 
értékeket ún. vödrökbe (bucket) rakják, ami- 
ben lineáris listában tárolódnak az eredeti 
kulcsok, azaz egy vödrön belül a keresés már 
nem gyors, csak lineáris, és nem a hasheket, 
hanem az eredeti típusokat kell összehason- 
[ítani 

Amikor a build input kész az egész (de a 
kisebb) táblára, akkor a szerver elkezd végig- 
menni a nagyobbik táblán, és megnézi, ben- 
ne van-e a tábla adott joinkulcsa a build in- 
putban. Ehhez lehashelik ennek is a kulcsát, 
majd a vödrök között felezős kereséssel gyor- 
san megtalálják azt a vödröt, amelyikben 
benne lehet a keresett kulcs. A vödrön belül 
lehet számtalan tétel, amelyekkel már tény- 
legesen össze kell hasonlítani a kulcsokat. 
Ha a kulcs megvan, nyertünk, a két tábla az 
adott kulcs mentén összeilleszthető. Ezt a fo- 
lyamatot ismétlik meg a másik tábla minden 
egyes kulcsára, ez egyébként a probe input. 

Ez a hash join, és elég gyors még indexe- 
letlen táblákra is, de mindkét táblán egyszer 
végigmegy. Nagyon nagy tábláknál (százmil 
lió soros) azonban még ez a folyamat is las- 
súvá válik. Képzeljük el, hogy egy százmillió 
soros ténytáblát kell 5 egyenként tízezer so- 
ros dimenziótáblához joinolni. A tízezer so- 
ros dimenziótáblák kulcsaiból viszonylag kis 
költséggel felépíthető a build input, azonban 
ez után végig kell menni a százmillió soros 
ténytáblán, és a kulcsait lehashelve minden 
egyes dimenziótábla hashtáblájában utána 
kell keresni. Ez már nagyon nagy IO- és pro- 
cesszorköltséget igényel. 


Ezen csillagsémás joinnak a költségét 





igyekszik csökkenteni a Bitmap Filter ope- 
rátor, eleve kidobva azokat a sorokat a probe 
inputból, a ténytáblából, amelyekről vala- 
milyen mágikus módon tudjuk, hogy biztos 
nincs hozzájuk passzoló sor a többi táblában. 
Az SOL Server 2008 ún. Bloom filtert hasz- 
nál erre a célra. Ez egy érdekes adatstruk- 
túra, amellyel halmazokat lehet nagyon ha- 
tékonyan kezelni. Érdekessége: egy elemre 
tévesen azt mondhatja, hogy benne van a 
halmazban, pedig nincs, de sosem mondja 
azt, hogy nincs benne egy elem a halmazban, 
amit pedig a valóságban beleraktak. Mivel a 
szerver ezt a garantáltan nem egyező sorok 
kiszűrésére használja a hashtábla-keresések 
számának csökkentése érdekében, ezért nem 
probléma valamennyi false pozitív (azt hiszi, 
hogy benne van, de nincs) sor, mert a benn- 
maradt sorokra úgyis megnézzük hagyomá- 
nyos hash joinnal, hogy tényleg egyeznek-e a 
joinfeltételnek megfelelően. 

A Bloom filter egy bittömbben tárolja a 
halmaz elemeit. Úgy működik, hogy ha be 
akarnak rakni egy elemet a halmazba, akkor 
azt n féle hash-függvénnyel is lehashelik, és 
a hash-értékeknek megfelelő biteket egyre 
állítják egy bittömbben. Azaz például n-10 
hashfüggvény alkalmazása esetén 10 bitpo- 
zíció lesz I-re állítva, a hashek kimenetének 
megfelelő sorszámú. Más elemeket hozzáad- 
va persze egyre több olyan bit lesz, ami már 
eleve 1 volt a korábban behelyezett elemek 
miatt, így itt információ veszik el, emiatt a 
határozatlanság az elem tesztelése során. 

Hogy egy kulcs eleme-e a halmaznak, azt 
úgy nézik meg, hogy a kulcsot lehashelik a 
példabeli, mondjuk, 10 hash-függvénnyel, és 
megnézik, hogy ezek a bitek I-re vannak-e ál 
lítva. Ha mind be van állítva, akkor az elem 
valószínűleg eleme a halmaznak. De nem biz- 
tos. Nyilván minél kisebb a tömb, és minél 
több elemet tárolunk benne, annál többször 
csal, jól kell megbecsülni a méretét és a ha- 
shek számát is, ez a hibahatár nem túl bonyo- 
lult valószínűség-számítással előre belőhető. 

Az SOL Server csillagJoin esetén, miköz- 
ben minden egyes dimenziótáblához felépíti 
a build inputot, azaz lehasheli a kulcsaikat, 
közben építi a Bloom filtereket is, ezt hívja 
Bitmap Filternek. Minden egyes dimenzió- 
táblához készül tehát egy Bitmap Filter. Ezek 
után nekilát a ténytáblát soronként felolvas- 
ni. Normál esetben le kellene hashelni az 


összes kulcsoszlop-értéket a sorból, amely 
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valamelyik join-feltételben szerepel, és ráke- 
resni a megfelelő dimenziótábla hashtáblájá- 
ban. Ez lenne a sima hash join. Ehelyett azt 
csinálja a szerver, hogy végrehajtja a Bitmap 
Filterhez tartozó n féle hashképzést, és rápró- 
bálja azokat az első, általa legszelektívebbnek 
gondolt dimenziótábla Bitmap Filterére. Ha 
az azt mondja, hogy nincs benne az elem a 
halmazban, akkor ez garantáltan azt jelenti, 
hogy ez a sor kiesik a join miatt, így sem en- 
nek a dimenziótáblának a hashtáblájában, 
sem a többiében nem érdemes megnézni, 
benne van-e az elem. Ha az első bitmap filter 
nem ejtette ki a sort, akkor jön a következő 
dimenziótábláé. Ha mindegyiken átment a 
dolog, akkor még mindig megvan, ha na- 
gyon kicsi is a valószínűsége, hogy fals pozi- 
tív a sor, azaz valójában nincs is párja a többi 
táblában, ezért ilyenkor még meg kell csinál 
ni a rendes hash join procedúrát erre a sor- 
ra, Összepárosítva az Összes táblával. 

Ha olyan bitmap filtereket csinál a szer 
ver, amelyek elég szelektívek, azaz sok sort 
előre kiejtenek, akkor nagy nyereséget érhe- 
tünk el a kevesebb hash join miatt. 

Okos a szerver, ha menet közben észreve- 
szi, hogy nem a legszelektívebb filter van elöl, 


átrendezi a listáját. Ez végül is minimális 





2 Microsoft SOL Server Management Studio 
File Edit View  Ouery Project Tools 
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SELECT D.CalendarYcar, D.Calendarfuarter, T.SalcsTerritoryCountry 
FROM dbo.FactIlInternetSales2 F 
INNER JOIN dbo.DimDatc D ON F.OrderDatekcy — D.Datckcy 
INNER JOIN dbo.DimSalesTerritory T ON 
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statisztikázással nyomon követhető a részé- 
ről. A bitmap filtert csak párhuzamos tervek 
esetén használja az SOL Server (2. ábra), hisz 
csak nagy költségű lekérdezéseknél érdemes 
vesződni vele, illetve az algoritmusból látha- 
tó, hogy az jól párhuzamosítható. 

A 2. ábrán a bekarikázott részekben látha- 
tó az a lépés, amely felépíti a Bitmap Filtert 
(a Bloom Filtert) a DimDate és a DimSales- 
Territory táblákhoz. Miután a szűrők készen 
vannak, indul az alsó Iable Scan operá- 
tor, amely a FactlnternetSales2 táblán megy 
végig, előszűrve az adatokat az előbbi két 


Filterrel. A szűrési feltétel így néz ki: 


PROBE([Opt. Bitmap1007], fAdventureWorksDWJ]. [dbo].[Fa 
ctinternetSales2]. [SalesTerritoryKey] as (FI.[SalesTerritoryK 
eyI,NTIN ROW?) AND PROBE(IOpt . Bitmap1008], [Advent 
ureWorksDWI.[dbo].[FactinternetSales2].[OrderDatekKey] as 
[FJ.[OrderDateKey],NIN ROWT) 


Az SOL 2005 is ismerte már a Bitmap 
Filtert, de csak statikusan, a terv generálá- 
sa közben döntötte el, hogy használni fog 
filtert, míg az SOL 2008 a közbenső joinok 
végrehajtása közben is dinamikusan képes 
dönteni róla, hogy elég volt a hagyományos 
hash joinból, itt bizony bitmap filtereket kell 


építeni. 
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Tömörítés (adat és mentés) — 
Page Compression 
Az adattárházak tábláit sokkal többet olvas- 


sák, mint módosítják. Erre a tényre épít az 
adatlapok tömörített tárolása, amely jelentős 
IO-költséget spórolhat meg viszonylag kevés 
processzorköltség árán. 

Az SOL 2005 SP2 már bevezette a vardeci- 
mal tömörített típust, amely nem fix hosszú- 
ságon tárolja ezeket a számokat, csak olyan 
hosszan, amennyi az adott példány tényle- 
ges tárolásához kell. Például a 2.23 keve- 
sebb helyet kér, mint a 2234234.23 vagy a 
3.345353535345. Változó hosszúsággal ábrá- 
zolják tehát az egyébként fix hosszúságú deci 
mal adatot, ezzel helyet spórolnak meg. Gon- 
dolom, nem kell mondanom, miért pont ezt 
a típust rakták be az SP2-be! Azért, mert a 
pénzmennyiségeket ebben szoktuk tárolni 
(nem kettes, hanem 10-es számrendszer ala- 
pú, ezért véges tizedes törteket pontosan tud 
ábrázolni, szemben mondjuk a reallel, ami 
2-es számrendszer alapú). 

Az SOL Server 2008 ezen a vonalon ment 
tovább, és már nemcsak a decimalt, hanem a 
többi fix hosszúságú adatot is tudja változó 
hosszal, azaz tömörítve tárolni. 


Mielőtt azonban megbeszélnénk az ösz- 
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szes tömörítési módszert, nézzük, miért jó ez 
nekünk! A tömörítés elsődleges célja az IO- 
költségek csökkentése, ezáltal a lekérdezések 
gyorsítása. Az adatmódosítások nyilván las- 
sulnak, ezért elsősorban általában csak ol 
vasott adatokra érdemes használni. Nincs 
dráma a módosításnál, de pár százalékkal 
lassabb lehet. A backup is gyorsul, hisz keve- 
sebb adatot kell kimásolni. A backup is tud 
tömöríteni 2008-ban, a kettő egymástól füg- 
getlen, és használható együtt, erről is lesz szó 
hamarosan. 

Mivel tömörebbek az adatlapok, jobban 
kihasználható a gép memóriája cache céljá- 
ra, azaz egy 2-szeres tömörítés hasonló ha- 


tású, mint ha dupla annyi memóriánk len- 


alamizsna 
alamuszi 
lakatos 


3. ábra. Column-prefix tömörítése 


ne cache céljára. Ez ezért lehetséges, mert a 
felolvasott lapokat nem tömöríti ki a szerver 
a memóriában, hanem eredeti formájában 
tárolja. 

Lehet tömöríteni adatot, indexet és akár 
egy tábla vagy index bizonyos partícióit is. Ez 
utóbbi nagyon jó, mert így az archív adatokat 
lehet tömörítve tárolni régebbi partíciókban, 
míg az éppen töltött adatokat tömörítés nél 
kül, hogy ne lassuljanak a DML-műveletek. 

Hogyan tömörít az SOL Server 2008? 
Azért azt látni kell, hogy nem lehet egy zipet 
vagy egy rart berakni a szerverbe, mert bár az 
valószínűleg nagyobb tömörítési arányt érne 
el, de sokkal lassabb lenne tőle a feldolgozás. 
Olyan tömörítés kellett, ami elég sokat tö- 
mörít, de nem túl nagy költséggel. Egyféle 
technikáról bár beszéltem, a fix adatok vál 
tozó hosszúságú kódolásáról. Ez működik a 
számokra és a char, nchar típusra. Kívülről 


persze ez nem látszik, az int továbbra is 4 báj- 


tosként néz ki, annak ellenére, hogy belül le- 
het, hogy csak 1,5 bájtot igényel. Row comp- 
ression néven érhető el ez a tömörítés. 

Főleg szöveges adatok esetén azonban ez a 
módszer nem tudna nyereséget adni, maxi- 
mum ostobán megszerkesztett hosszú char, 
nchar oszlopoknál, de van annyi eszünk, 
hogy változó hosszúságú adatokat zvarchar 
és társaiban tárolunk. Más módszer kell 
a tömörítésre, ez pedig a sorok közötti re- 
dundancia csökkentésével működik. Az első 
módszer az adatok első részében, prefixében 
levő redundanciát űzi el (3. ábra). 

Például az aladár és az alamizsna szavak- 
ban az alamizsna bájtokat csak egyszer írják 


le a lap fejlécében mondjuk l-es indexszel, 


Anchor sor 


alamizsna 
3dár 
k£null; 
4uszi 
olakatos 





és a mezőkben csak 3dár és 3mizsna lesz. A 
3 azt jelenti, hogy az anchor sor első három 
bájtját kell venni, majd mögé rakni a letárolt 
adatot (ala § mizsna). Ha egy sor értéke egy- 
általán nem származtatható az anchor sor ér- 
tékéből (lakatos), akkor persze nem nyerünk, 
hanem vesztünk a tömörítéssel. A storage 
engine persze észreveszi ezt, és fenntartja 
magának a jogot, hogy bár be van kapcsolva 
a tömörítés egy tábla lapjaira, egyes lapokat 
mégse tömörítve tároljon. 

Ez a columnprefix tömörítés. 

A másik módszer szótár alapú, azaz ha pél- 
dául a 3dár bájtok egy lapon 15 sorban is 
szerepelnek bármely oszlopban, akkor csak 
egyszer tárolják le a lap fejlécében, és a so- 
rokba mutatókat raknak az adatszótár adott 
bejegyzésére. 

Azaz a két módszer együtt működik, elő- 
ször a közös prefixeket emelik ki, majd meg- 


nézik az eredő képet, és azt a szótárazós mód- 





szerrel tovább tömörítik. Ez a két módszer 
együtt a page compression. 

Persze a lapszintű tömörítések nemcsak 
szöveges, hanem bináris adatokra is men- 
nek, csak így könnyebb volt szemléltetni a 
folyamatot. 

Melyiket használjam? A row compression- 
nek jóval kisebb a költsége, ezért a gyakrab- 
ban lekérdezett vagy módosított adatokhoz 
ez megfelelőbb. Cserébe nem tud annyira 
tömöríteni. 

A gyakran használt indexeket valószínűleg 
nem érdemes tömöríteni, csak azokat, ame- 
lyek nagyok, de ritkán használatosak. 

Kis táblákra kár használni bármelyik 
módszert is, csak izzítjuk vele feleslegesen a 
procikat. 

Index seek-reken (pontszerű lekérdezések: 
nél) nem sokat javít a tömörítés, mert egy- 
egy sor miatt akár 6-8 lapot is ki kell csoma- 
golni, ami felesleges költség. Range seek-ekre 
vagy index scan-ekre már megéri, azaz, ami- 
kor nagyobb tartományokra kerestetünk, így 
eleve sok adatlapot érintene a lekérdezés (az 
előbbi példa hash joinja például ilyen volt). 
A sys.dm db index operational stats né- 
zet megmutatja, melyik index mennyire és 
milyen módon van kihasználva, ez segíthet 
eldönteni, melyik indexeket érdemes tömö- 
TÍtENI 

A nagy adatokra, mint varchar(max) és 
társai nem működik a tömörítés, hisz az 
előbb leírt módszerek nyilvánvalóan nem 
mennek csak apró adatokra, ezeket inkább 
a hagyományos stream alapú tömörítésekkel 
lehet összepakolni. Mit lehet tenni, ha ezeket 
is tömöríteni akarjuk? 

1. Az alkalmazás maga tömörít. A mai vi- 
lágban ez már nem nagy szám, szinte minden 
keretrendszerben megvannak hozzá a szüksé- 
ges osztályok vagy függvények. 

2. Tömörítő CLRfüggvényt írunk, azzal 
tömörítünk a tárolás előtt, mondjuk, egy tá- 
rolt eljárásban. 

3. Olyan CLRtípust implementálunk, 
ami tömörítve tárolja a belepumpált adato- 
kat. A méretlimit feloldása miatt ez minden 
további nélkül lehetséges. 

4. Az előző számban tárgyalt FILE- 
STREAM oszlopot használjuk tömörített 
NTEFS-könyvtárban. Ez nem tömörít olyan 
agresszíven, de elég gyors, és nincs vele sem- 
mi dolgunk a konfiguráláson kívül. 


Tegyük fel, rájöttünk, kell nekünk a tömö- 
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rítés. Mielőtt azonban bezipelnénk az uni- 
verzumot, érdemes kicsit méricskélni, mit 
várhatunk el tőle, hisz az adatainktól nagy- 
ban függ, mekkora lesz a nyereségünk, ha 
egyáltalán lesz. 

Az — sp estimate data compression. sav- 
ings tárolt eljárással ki lehet próbáltatni, 
hogy egy adott tábla vagy index egy adott 
partícióján a row vagy page compression 
mennyit hozna a konyhára. Az sp persze nem 
áll neki a 80 exabájtos táblát betömöríteni, 
hanem mintavételezéssel készít egy kis min- 
tatáblát a tempdb-ben, és azt csomagolgatja, 
majd ennek eredményét vetíti vissza (tudo- 
mányosan: extrapolálja) az eredeti táblára. 

Nézzünk egy konkrét példát (a kimenetet 


lerövidítettem, és átneveztem az oszlopokat): 


execsp. estimate data compression savings Production, 
"TransactionkHistoryArchive", NULL, NULL, "row 

execsp. estimate data compression savings Production, 
"TransactionkHistoryArchive", NULL, NULL, "page" 


object name index id eredeti méret (KB) tö- 
mörített (KB) 

TransactionHistoryArchive. 1] 5136 3240 
TransactionHistoryArchive. 2 1144 968 
TransactionHistoryArchive. 3 1488 1240 
object name index id eredeti méret (KB) tö- 
mörített (KB) 

TransactionHistoryArchive. 1] 5136 1680 
TransactionHistoryArchive. 2 1144 816 
TransactionHistoryArchive. 3 1488 1144 


Mit látunk? Az alapban 5,1 megabájtos 
adatból és rajta levő 2,7 megányi indexből 
row compressionnel 3,2 és 2,2 mega lesz. 
Az adat kb. a felére megy össze, ami nem 
rossz, hisz row compressionről van szó, ami 
nagyon gyors. Az indexet nem tudta úgy Ösz- 
szenyomni, valószínűleg az indexekben levő 
int adatok jelentős része 2 bájt hosszan tá- 
rolható csak (nagy számok), így csak felére 
tömöríthető. 

Lapszintű tömörítésnél az 5,1 megás ada- 
tok csak 1,7 megát foglalnak el, azaz 3-szoros 
tömörítést kapunk. Az indexek összmérete 
2,7xől 1,95 megára esik vissza, nem sokkal 
kisebbre, mint csak sortömörítéssel (2,2). 
Szóval indexnél esetünkben nem sokat ért 


egyik módszer sem, az adatok jellege miatt. 


Én lehet, hogy indexnél semmilyen vagy 
csak sor, adatnál pedig lapszintű tömörítést 
használnék. 

Az adatok tényleges tömörítése lapszin- 


ten: 


alter table Production. TransactionHistoryArchive 
rebvild with (data. compression — page); 


Nézzük meg, mit nyerünk! 


select index id, index level, index type desc, 

page. count, compressed page count, 

(select top 1 name from sys.indexes si 

where si.object id — s.object id and 

si.index id — s.index id) index name 

from sys.dm db index physical stats(DB 

ID(N"AdventureWorks"), 

object. id( Production. TransactionkHistoryArchive"), NULL, NULL, 
"DETAILED") 

as s order by s.index id, s.index level desc 

i idi level index type desc page count 

compressed pcindex name 


1 1  (CLUSTERED 1 0 
PK ...IransactioniD 

1 0  CLUSTERED 203 203 
PK ...TransactioniD 

2 1 — NONCLUSTERED 1 0 


IX ...ProductID 
2 0 — NONCLUSTERED 125 000 
IX ...ProductID 


3 1 — NONCLUSTERED 1 0 
IX. ...ReferenceOrderiID 

3 0 — NONCLUSTERED 168. 0 0 
IX ...ReferenceOrderiID 


Látható, hogy a clustered index 1. szintje 
(1. sor), azaz az index gyökérlapja nem page, 
csak row tömörített, de a 203 levélszintű lap, 
azaz az adatlapok mind page tömörítettek 
(2.801), 

Látható az is, hogy az indexek egyáltalán 
nincsenek tömörítve, az alter table clustered 
index esetén csak arra és az adatra vonat 
kozik, a nonclustered indexekre nem. Ha 
azokat is tömöríteni akarjuk, alter index pa- 


rancsra lesz szükségünk: 


alter index IX. TransactionHistoryArchive ProductiD 
on Production. TransactionHistoryArchive 
rebvild with (data. compression — page); 


i idi level index type desc page count 
compressed pcindex name 


1 1  CLUSTERED 1 0 
PK ...IansactionID 

1 0  CLUSTERED 203 203 
PK ...IansactionID 

2 1  NONCLUSTERED 1 0 

IX ...ProductiD 

NONCLUSTERED 90 89 

IX ...ProductiD 

3 1 — NONCLUSTERED 1 0 
IX. ...ReferenceOrderiID 

3 0 — NONCLUSTERED 168 0 0 0 
IX. ...ReferenceOrderiID 


Szinte minden indexlap page compressed 
lett (89), csak 1 maradt row compressed (a 
gyökéren kívül). 

Hasonlítsuk össze a teljes tábla kiolvasá- 
sának IO-költségét a page tömörítéssel és 


simán: 


set statistics io on 
select " from Production. TransactionHistoryArchive 


alter table Production. TransactionkHistoryArchive 
rebvild with (data. compression — none); 


select " from Production. TransactionHistoryArchive 
set statistics io off 


Table TransactionHistoryArchive". Scan count 1, logical reads 
205, physical reads 0, read-ahead reads 0, lob logical reads 0, 
lob physical reads 0, lob read-ahead reads 0. 


Table TransactionHistoryArchive". Scan count 1, logical reads 
622, physical reads 0, read-ahead reads 0, lob logical reads 0, 
lob physical reads 0, lob read-ahead reads 0. 


Harmadára esik vissza az IO (633 2: 205 ), 
a háromszoros tömörítés miatt. 

Összegezve, a tömörítés igen hasznos szolk 
gáltatás, amely hatalmas táblák esetén jelen- 
tősen csökkentheti az IO-költséget, így ha az 
a szűk keresztmetszet, akkor nem csak spórol 


a merevlemezzel, de még gyorsít is. 


Backup Compression 
A mentés tömörítésének célja a mentés mé- 
retének csökkentése, akár jelentős CPU-költ 


ség árán is. 


backup database HungarySpatial 
to disk— cAtemph.bek 


Processed 192936 pages for database "HungarySpatial , 
file... on file 1. 


A 





Processed 2 pages for database "HungarySpatial , file"... 
on file 1. 

BACKUP DATABASE successfully processed 192938 pages in 
153.180 seconds (9.840 MB/5ed. 


backup database HungarySpatial 
to disk— c-Yempihc. bek 
with compression 


Processed 192936 pages for database HungarySpatial , 
file... on file 1. 

Processed 1 pages for database "HungarySpatial , file"... 
on file 1. 

BACKUP DATABASE successfully processed 192937 pages in 
73.008 seconds (20.645 MB/5ed. 


Látható, hogy ebben a konfigurációban 
(laptop) a tömörítés processzorigényét mesz- 
sze meghaladta az a nyereség, amit a kisebb 
backup fájl miatti kevesebb IO-val nyertünk, 
így a mentés kb. feleannyi idő alatt lefutott. 
Egyébként az eredeti mentés mérete 1508 
megabájt volt, a tömörített 242. Ez igen 
nagy arány, jelentősen nagyobb, mint amit a 
laptömörítésnél láttunk (6-szoros). Cserébe 
sokat kellett dolgoznia a processzornak, de 
ha a mentés eleve kevésbé terhelt időszakban 
történik, amikor amúgy is ejtőzik a proci, ak- 
kor nagyon sokat nyerhetünk a tömörített 
mentéssel. 

Érdekes kérdés lehet még, hogy a kétféle 
tömörítés használható-e együtt? A két szol 
gáltatás ortogonális egymásra, magyarul tel 
jesen független, tetszés szerint ki-be kapcsol 
ható mindkettő. 

Egy durva tesztként tömörítsük be az előb- 
bi adatbázis minden tábláját page compres- 
sionnel (ha van értelme, ha nincs), és készít 
sünk így is kétféle mentést. Egy táblázatban 


összefoglalom a mérések eredményét: 


Adat 9.840 MB/s; 20,045 MB/s; 
nem tömörített 1508 MB 242 MB 








A kétféle tömörítés együttes használatával 


10-szeres tömörítést értem el ezen az adat 
bázison, ám nem sokkal rosszabb eredményt 
értem el tisztán backup tömörítéssel is. Az 
adattömörítés jótékony hatású a mentésre is, 
hisz a kevesebb , nyers" adat miatt kevesebb 


információt kell menteni. 


Az is látható, hogy a mentés tömörítés a 
lehető legnagyobb nyereségre törekszik, nem 
törődve a CPU-költséggel, míg az adattömö- 
rítés beéri szerényebb tömörítéssel, de cseré- 
be csak minimális CPU-időt használ. 


Grouping Sets 

A GROUP BY egyféle szempont, akárhány 
oszlop vagy kifejezés alapján csoportosít, az- 
tán aggregáló függvényekkel dolgozhatjuk 
fel a többi oszlop adatait. [dőnként azon- 
ban többféle szempont szerint is kellene cso- 
portosítani. Például eladások év alapján, elt 
adások év és termék alapján, eladások csak 
úgy, összesen stb. Ezt meg lehet tenni több 
lekérdezés UNION ALL/jával, amelyek ele- 
je majdnem ugyanaz, csak a GROUP BY-ok 
mások. 

Valami hasonlót csináltak már a korábbi 
SOL Serververziók is CUBE és ROLLUP zá- 
radékkal a GROUP BY után. Ezekbe be volt 
építve, hogy ne csak a megjelölt oszlopok 
szerint csoportosítsanak, hanem egyre több 
csoportosító oszlopot elhagyva egyre dur- 
vább, egyre nagyobb átfogással dolgozzanak. 
A CUBE az összes GROUP BY oszlop min- 
den kombinációját képezte, azaz N oszlop 
esetén 2" féle csoport keletkezett. 

A ROLLUP N:I szempont szerint cso- 
portosít. 

Az új GROUPINGSET záradék a GROUP 
BY után arra szolgál, hogy mi, explicit meg- 
adhassunk több csoportosító feltételt is, így 
többféle dimenzió mentén aggregálhassunk. 
Azaz, ha akarunk, eljuthatunk a ROLLUP 
ig, illetve a CUBE-ig is, de kihagyhatunk tet 
szés szerinti szempontokat is. 

Ez nem más tehát, mint egy testre szab- 
ható átmenet a sima egyes GROUP BY 
és a mindenféle kombinációban aggregáló 
CUBE között. 

Az alábbi példában zárójelben odaírtam, 
hogy melyik csoportosító feltétel melyik ki 


meneti sort generálja: 


SELECT D.CalendarYear Y, D.CalendarOvarter 0, 
T.SalesTerritory Country ST, 

SUN(F SalesAmount) AS SA 

FROM dbo.FactinternetSales F 

INNER JOIN dbo.DimDate D ON F.OrderDateKgy — D.DateKey 
INNER JOIN dbo.DimSalesTerritory T ON 

F.SalesTerritory Key — T.SalesTerritoryKey 

GROUP BY GROUPING SETS ( 

(CalendarYear, CalendarOuarter, SalesTerritoryCountry), -—-( 1) 
(CalendarYear, CalendarOvarter), --(2) 


(SalesTerritory Country), --(3) 
ME-t8) 


Vad] SA 

NULL NULL NULL 80450596 (4) 
NULL NULL Australia 159459558) 
NULL NULL Canada TASZZGZSKÓ] 
2001 3 NULL 2193683 (2) 

2001 3 Canada 63/7982 (1) 


2001 3 United States 
2001 4 NULL 


2555651 (1) 
4871801 (2) 


Egyébként nemcsak egyszerűbb a formá- 
tum az eddigi UNION-os megoldáshoz ké- 
pest, hanem gyorsabb is a GROUPING SET, 


mert egy menetben megy végig az alaptáblán, 





Microsoft" 


SOL Server 2008 


Az SOL Server 2008 új logója 








és felhasználja a finomabb felbontású aggre- 
gált eredményeket a durvábban. A végrehaj- 
tási tervből látható lenne, hogy először ki 
számolja a CalendarYear, CalendarOuarter, 
Saleslerritory Country csoportosításnak 
megfelelő összegeket, majd a CalendarYear, 
CalendarOuarter alapút ebből, és nem az 
eredeti adatokból adja össze, ezzel erőforrá- 


sokat megtakarítva. 


Zárszó 

Láthattuk, hogy az adattárházak kezelésé- 
hez rengeteg új szolgáltatást kaptunk az SOL 
Server 2008-ban, amelyek legtöbbje nem 
csak adattárházakban, hanem tetszőleges al 
kalmazások esetén is jelentős teljesítmény- 

nyereséget okozhat. 
Saczó Zsölt 
MCSD, MCDBA, ASP.NET MVP 
(http://soci.hu) 
Research Engineer 
Nvalification Development Kft. 
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A Fujitsu Siemens Computers áttörő IT infrastruktúra-megoldásai éppoly rugalmasan alkalmazkodnak 
a váratlan helyzetekhez, mint On. 


A Fujitsu Siemens Computers FlexFrame" Infrastructure rendszere tökéletesen illeszkedik az adatközponti 
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